On Fri, Aug 5, 2011 at 8:42 PM, William Hubbs <willi...@gentoo.org> wrote: > On Fri, Aug 05, 2011 at 10:06:48PM +0200, Sven Vermeulen wrote: >> How does the tool that creates an initramfs know which files to copy from >> /usr and /var anyhow? > > My understanding is that nothing gets copied from /usr and /var, and it > doesn't have to. > > Here is my basic understanding of how the boot sequence works: > > 1) rootfs is mounted on /. Rootfs contains the contents of the > initramfs.
Ok, so the initfs is typically in /boot, though it need not be. It needs to be someplace the bootloader can find it, and with grub legacy that typically means on a bare hard drive partition, or one using md raid-1 with older metadata. The initramfs doesn't need to find itself - the bootloader loads it into ram and passes its address to the kernel when executing it. > 2) the init program inside the initramfs is run. > 3) This init program will mount the real /usr and /var. So, this is the chicken and egg bit that led to the question about how the tool that creates initramfs knows what to copy from /usr, etc. If /usr can be mounted without any files from /usr, then clearly booting without /usr mounted shouldn't be a problem (just mount it early). If it does need files from /usr, then the initramfs has to contain those files since /usr isn't mounted yet. The answer isn't that complicated - the tool just knows what files are needed from a hardcoded list/etc. It might also use some static linked tools. It might also use a subset of the regular udev/etc tools - it doesn't need to configure your video capture card and mouse - it just needs to find anything that could contain the root filesystem (and now /usr as well). Keep in mind the initramfs does not need to fully initialize the system, and it doesn't need to do it in a way compatible with anything that will subsequently load. It doesn't need to populate /dev the way the rest of the stuff in the distro expects it to be, since the /dev it is populating will get unmounted/wiped/etc before switching roots. Initramfs just has to quickly operate in a scratch filesystem, mount the real filesystems, then wipe itself out and chroot. It doesn't need to be compatible with the latest version of dbus/hal/X11/openrc/etc - it just needs to be internally self-consistent. For whatever reason it still isn't working for me (using dracut) - for some bizarre reason it can't auto-detect my raid, even though running mdadm --assemble --scan and exiting the dash shell allows it to boot. Oh well - I'm sure I'll work it out. Then of course somebody needs to patch it to mount /usr as well, or grab a copy of whatever Fedora is doing if it is open source. And as previously stated I'm fine with a more minimal initramfs being provided as well, although my feeling is that if the dracut solution works reliably it seems redundant. In fact, dracut -H creates a host-only solution that should only have minimal drivers installed, and once it finishes running it should free any RAM it is using and not leave any processes around. Rich
