X-Git-Url: https://git.decadent.org.uk/gitweb/?p=i-t-talk.git;a=blobdiff_plain;f=index.html;h=ac4bf8dcdbd574c46ecfdfca432137b590d057c8;hp=11a89d14c9cab9c22c5f00fbbf85b6a8f0553fc0;hb=HEAD;hpb=b909ede4aceab0e41d063205f31ceb8c1d7f8c9a

diff --git a/index.html b/index.html
index 11a89d1..ac4bf8d 100644
--- a/index.html
+++ b/index.html
@@ -53,6 +53,205 @@
 <h3>Ben&nbsp;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>
@@ -92,6 +291,9 @@ OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
 WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
       -->
     </li>
+    <li>
+      Xzibit promotional photo &copy; Retna, used for purpose of parody
+    </li>
   </ul>
 </div>