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

[Matthew Summers]

On Fri, Aug 5, 2011 at 7:42 AM, Rich Freeman <rich0@g.o> wrote:
> On Fri, Aug 5, 2011 at 6:16 AM, Marc Schiffbauer <mschiff@g.o> wrote:
>> * Robin H. Johnson schrieb am 05.08.11 um 02:46 Uhr:
>> [...]
>>> That leaves the only reasonable solution as #2. In terms of minimal
>>> impact, I propose that we offer users with a static system an absolutely
>>> minimal initramfs, that _just_ mounts the required directories.  No
>>> modules, no LVM, no MD, no crypto etc - if you want that functionality,
>>> go and use genkernel or dracut. If your fstab contains a line like:
>>> /dev/sdXN /usr ...
>>> Then this initramfs is for you.
>>>
>>> The minimal initramfs would do the following.
>>>
>>> 1. Mount devtmpfs/sysfs/procfs as needed to access devices.
>>> 2. Mount real_root to /newroot
>>> 3. Read /newroot/etc/initramfs.mount and /newroot/etc/fstab
>>> 4.1. If /newroot/etc/initramfs.mount does not exist
>>>      Assume it contains only: /usr /var
>>> 5. Mount the combined items from said files
>>> 6. pivot_root.
>>>
>>
>> That sounds like a good compromise to me!
>
> Why would we build yet another initramfs vs just making dracut work
> reliably?  You can already build dracut without support for
> lvm+raid+luks/etc.
>
> If we're going to require an initramfs then we should make sure that
> ALL gentoo-provided solutions work before we expand the need for a
> mounted /usr.  The genkernel team already mentioned that they plan to
> switch to dracut, so we really just need to get dracut working
> properly.
>
> That said, nobody is preventing anybody from re-inventing the wheel if
> they wish to do so.  I just wouldn't just offer it up as an example of
> a perfectly acceptable migration strategy, when we've had a lvm+raid
> howto for years that wouldn't be compatible with it.
>
> Rich
>
>

In point of fact all modern Linux kernels have an initramfs built in
now, that when empty is effectively bypassed, so there is no wheel
reinvention. To quote the docs [1]
"
All 2.6 Linux kernels contain a gzipped "cpio" format archive, which is
extracted into rootfs when the kernel boots up.  After extracting, the kernel
checks to see if rootfs contains a file "init", and if so it executes it as PID
1.  If found, this init process is responsible for bringing the system the
rest of the way up, including locating and mounting the real root device (if
any).  If rootfs does not contain an init program after the embedded cpio
archive is extracted into it, the kernel will fall through to the older code
to locate and mount a root partition, then exec some variant of /sbin/init
out of that.
"
[1] /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt

While dracut may help with the process of creating the initramfs, its
really not a terribly complicated endeavor, and from further reading
(specifically as related to the desired removal of md autodetection),
it is the full intention of the kernel upstream that initramfs be the
new path forward in handling things such as separate /usr, raid
volumes, and so on. Further, dracut will introduce yet another dep in
base-system (I am guessing here), that is not more than perhaps a
convenience. I note here, that I have not used dracut as the well
documented method of creating an initramfs is straight forward enough
that I did not require anything too fancy to handle mounting raid1
volumes, and providing a recovery environment with networking and ssh.

This, at least to me, seems like an excellent opportunity to nicely
document what can be done with an initramfs (in basic and advanced
forms, as there are some really fancy things one can do with
initramfs's), and how Gentoo is recommending their usage in the cases
outlined by Robin and others.

So, I am +1 on robbat2's solution and -1 on dracut. That said, I am
fully willing to alter my position when presented with a better
argument. Lastly, I do have a few minor concerns about how this
"default" initramfs will be dealt with, however those can wait.
Mainly, I simply desire the flexibility to replace the Gentoo-shipped
version with a custom version easily.

Thanks and kind regards,
Matt

-- 
Matthew W. Summers
Gentoo Foundation Inc.