On Fri, Aug 5, 2011 at 7:42 AM, Rich Freeman <ri...@gentoo.org> wrote: > On Fri, Aug 5, 2011 at 6:16 AM, Marc Schiffbauer <msch...@gentoo.org> 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.
