Re: [gentoo-dev] /usr vs. initramfs redux

[Rich Freeman]

On Fri, Aug 5, 2011 at 8:42 PM, William Hubbs <williamh@g.o> 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