<h3>Ben Hutchings</h3>
</div>
+<div class="slide">
+ <h1>What is the initramfs for?</h1>
+ <ul class="incremental">
+ <li>
+ Huge variety of disk drivers, net drivers and filesystems that
+ may be needed to mount root
+ </li>
+ <li>
+ Generic kernel shouldn't have all these built-in
+ </li>
+ <li>
+ Root might also need RAID, LVM, dm-crypt, which generally need
+ to be configured by userland
+ </li>
+ <li>
+ Kernel needs a way to load modules and run scripts but
+ it can't read them from the root filesystem
+ </li>
+ <li>
+ Solution: boot loader provides a bundle of files
+ (initramfs image) to the kernel
+ </li>
+ </ul>
+</div>
+
+<div class="slide">
+ <img src="yo-dawg.jpeg" width="90%" />
+</div>
+
+<div class="slide">
+ <h1>How the kernel uses an initramfs</h1>
+ <ul class="incremental">
+ <li>
+ Kernel <em>always</em> mounts an initial root filesystem using
+ either ramfs or tmpfs
+ </li>
+ <li>
+ If the boot loader provides an initramfs image, kernel
+ unpacks it into this filesystem, then runs <tt>/init</tt>
+ </li>
+ <li>
+ The initramfs init system is then responsible for mounting
+ the real root filesystem and running the real <tt>init</tt>
+ <ul class="incremental">
+ <li>
+ Although it is not <em>required</em> to hand over at all
+ - e.g. debian-installer
+ </li>
+ </ul>
+ </li>
+ </ul>
+</div>
+
+<div class="slide">
+ <h1>Overview</h1>
+ <ul class="incremental">
+ <li>
+ Started in Ubuntu in 2005 and adopted in Debian later that year
+ </li>
+ <li>
+ <tt>mkinitramfs</tt> builds an initramfs image using the
+ included scripts, necessary kernel modules, udev, and utilities
+ from klibc-utils or busybox
+ </li>
+ <li>
+ Uses build-time and boot-time hook scripts for
+ extensibility
+ <ul>
+ <li>Used by btrfs-tools, cryptsetup, lvm2, mdadm, etc.</li>
+ </ul>
+ </li>
+ <li>
+ Supports dependencies within each set of scripts
+ </li>
+ </ul>
+</div>
+
+<div class="slide">
+ <h1>The init system</h1>
+ <ul class="incremental">
+ <li>
+ Mount <tt>devtmpfs</tt>, <tt>devpts</tt>, <tt>procfs</tt>,
+ <tt>sysfs</tt>, <tt>tmpfs</tt> at <tt>/run</tt>
+ </li>
+ <li>
+ Run <tt>init-top</tt> scripts - includes starting udev
+ </li>
+ <li>
+ Load explicitly configured modules
+ </li>
+ <li>
+ Run <tt>init-premount</tt> scripts
+ </li>
+ <li>
+ Run <tt>local-top</tt> or <tt>nfs-top</tt> scripts
+ - e.g. mdadm setup
+ </li>
+ <li>
+ Run <tt>local-premount</tt> or <tt>nfs-premount</tt> scripts
+ - e.g. btrfs scan, resume from disk
+ </li>
+ <li>
+ Mount root filesystem
+ </li>
+ </ul>
+</div>
+
+<div class="slide">
+ <h1>Problems (1)</h1>
+ <p>
+ Root filesystem is not enough. Depenency-based boot means
+ there's no clean split between root and <tt>/usr</tt>. So
+ initramfs should mount it (implemented in 0.117). However:
+ </p>
+ <ul class="incremental">
+ <li>
+ initscripts and mountall won't remount it read-write if it's
+ already mounted read-only
+ <ul class="incremental">
+ <li>
+ Current workaround: only do this for systemd
+ </li>
+ </ul>
+ </li>
+ <li>
+ fsck will refuse to operate on <tt>/usr</tt> if already
+ mounted
+ <ul class="incremental">
+ <li>
+ So we need to fsck it from the initramfs
+ <ul class="incremental">
+ <li>
+ But <tt>e2fsck</tt> complains if the superblock
+ time is newer than system time, and system time
+ may not be correct yet
+ <ul class="incremental">
+ <li>
+ So we need to fix the system time in the
+ initramfs
+ </li>
+ </ul>
+ </li>
+ </ul>
+ </li>
+ </ul>
+ </li>
+ <li>
+ Selecting the right fsck to install is harder than
+ it seemed
+ </li>
+ </ul>
+</div>
+
+<div class="slide">
+ <h1>Problems (2)</h1>
+ <p class="incremental">
+ Device discovery by kernel is asynchronous. But that's
+ why we have udev, right?
+ </p>
+ <p class="incremental">
+ Unfortunately not everything needed for device setup is
+ or can be in udev hooks (e.g. cryptsetup requires interaction)
+ </p>
+ <p class="incremental">
+ Lots of hacks used (<tt>while ... do sleep... done</tt>,
+ <tt>udevadm settle</tt> in too many places), and they still
+ sometimes fail
+ (<a href="https://bugs.debian.org/616689">#616689</a> and merged
+ bugs)
+ </p>
+ <p class="incremental">
+ Ubuntu has a somewhat better approach but we still haven't merged
+ it back...
+ </p>
+ <p class="incremental">
+ ...in fact, Debian and Ubuntu branches have been diverging for
+ about 5 years
+ </p>
+</div>
+
+<div class="slide">
+ <h1>More information</h1>
+ <ul>
+ <li>
+ Manual pages: <tt>initramfs-tools(8)</tt>,
+ <tt>update-initramfs(8)</tt>, etc.
+ </li>
+ <li>
+ Source docs: <tt>docs/example_hook</tt>,
+ <tt>docs/example_script</tt>, <tt>docs/maintainer-notes.html</tt>
+ </li>
+ <li>
+ Mailing list:
+ <a href="mailto:initramfs-tools@packages.debian.org">initramfs-tools@packages.debian.org</a>
+ (really debian-kernel)
+ </li>
+ </ul>
+</div>
+
<div class="slide">
<h1>Questions?</h1>
</div>
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
-->
</li>
+ <li>
+ Xzibit promotional photo © Retna, used for purpose of parody
+ </li>
</ul>
</div>