Create initramfs

Yes indeed, you have every right to blame it. I want to refer you back in last May and in my proposal

http://linuxfromscratch.org/pipermail/lfs-dev/2006-May/057365.html

Although the current conditions in Lfs/Linux land are totally different than it was that time, many of those ideas still looking fresh, if not all of them; plus, and since in the meantime there were evolutions like lets say, git and kwm (virtualization in general), probably could be more additions in that list and some more additions to the editors list (Bryan) of course.

The problem is that who will give you the authorization to do such a venture?

Which exactly is your proposal, do you have something in mind?

Since I don't use DM or MD or LVM, it'd be a bit hard for me to test any of that stuff. But if an LFS mkinitramfs script (which doesn't exist yet, I know) wouldn't require cpio, I'd have no problems adding something like it to the book. The problem is, it may require cpio, and the book doesn't install that.

OTOH, the kernel tree has a usr/gen_init_cpio program, which could be used relatively easily as well. The mkinitramfs script would have to generate a text file (same format as the file in my current initramfs hint: different than anything I've ever seen, but not impossible to work with), then run gen_init_cpio on that file, and pipe the output through gzip and then to the initramfs location. (Say, /boot/initramfs-<kernel version>.gz?) Then of course grub would have to be told to load that as an initrd.

I'll see if I can come up with anything this weekend. (I was actually already planning on going to an initramfs setup myself, so I could use an HID keyboard even in the face of non-running bootscripts. My keyboard's PS/2 now, but if it dies (and it's 7 years old), I'd like to move to USB.)

Anyone mind if I use the /init script from the LiveCD's initramfs as a starting point for this initramfs's /init, and the LiveCD's initramfs Makefile as a starting point for the mkinitramfs script? I'm hoping that'd be a lot less work than starting completely from scratch (or from my hint).

Not really an objection, but:

• Ihe regular disk boot (i.e., root=...) support is not tested on the LiveCD initramfs.
• IMHO, Debian's yaird would be a better starting point.
• The set of packages in the book is not frozen. Suppose one finds a bug in udev rules and wants to update rules in initramfs. Then cpio is definitely preferred to usr/gen_init_cpio.

LVM or dmraid testing help will be available on the blfs-support list or via private mail, if needed.

I think this would be great to have. And if it means we have to add cpio to the book, no problem. Another thing to look at for ideas is here:

http://git.fedoraproject.org/?p=hosted/livecd;a=blob;f=creator/mayflower;hb=HEAD

That's what fedora uses to generate the initramfs for their livecd. It's not extremely featureful, but the device setup seems sane.

Replying to alexander@linuxfromscratch.org:

IMHO, Debian's yaird would be a better starting point.

Hmm. Yes, it's better tested, and yes, it's more widely used, and yes, it's supposed to be distro-independent (assuming somebody wants to write the proper template(s) for LFS). But based on reading the design goals page (http://yaird.alioth.debian.org/yaird.html), it seems like it's way more complicated than anything I was thinking.

Not that that's bad, but all the support for encrypted root, S390 stuff, NFS root, etc., seems like overkill. Ideally I'd like to come up with something that lets users add that stuff relatively easily themselves, by editing the (e.g.) /usr/share/mkinitramfs-<version>/init file and rerunning mkinitramfs. Of course that would require bash knowledge. Hmm.

There are also several kernel command line parameters that are unsupported (the ide*= stuff that the LiveCD just added, root=, etc.). They say root= isn't supported because it'd require hotplug (=udev) support and support for lots of FSes, but the LiveCD already does both of those. And I'd be OK adding lots of stuff to the initramfs, if that stuff is there to make it work the same on any (or at least most) x86-type machine(s) that boot to a local disk. Full persistent disk support should be there too, IMO. But NFS/encryption/etc. are a bit much IMO.

(Plus yaird also requires a cpio binary. :-P But maybe that's inevitable anyway.)

The set of packages in the book is not frozen. Suppose one finds a bug in udev rules and wants to update rules in initramfs. Then cpio is definitely preferred to usr/gen_init_cpio.

Only if a compiled kernel tree is not available... :-)

But I do think that scenario is entirely possible, so we should plan for it one way or another. What about a mkinitramfs "package" that contains a copy of gen_init_cpio (modified to handle taking the list of files from stdin) to be installed permanently, along with the mkinitramfs script that uses it, and /init? It'd be similar to the iana-etc package (small, specific, etc.), although it'd contain more than just config files.

Or, we could do this all in BLFS, and point the user there at the end of LFS if they have special booting needs. That may be preferable if cpio is required.

Replying to Bryan Kadzban:

Hmm. Yes, it's better tested, and yes, it's more widely used, and yes, it's supposed to be distro-independent (assuming somebody wants to write the proper template(s) for LFS). But based on reading the design goals page (http://yaird.alioth.debian.org/yaird.html), it seems like it's way more complicated than anything I was thinking.

We can certainly start simple and build up features over time. I mean, the first step is just to make sure that you could boot from a standard partition and that the process works in the book.

Or, we could do this all in BLFS, and point the user there at the end of LFS if they have special booting needs. That may be preferable if cpio is required.

This might not be a bad idea anyway. There's other stuff we could talk about in BLFS like generating the docbook docs, too. There's precedent with shadow, and there are spots in the BLFS book where we talk about adding kernel support for things, yet we don't discuss building the kernel at all.

But if the only thing stopping initramfs support in LFS is cpio, then I don't think that should be critical.

Plus, it would probably be a good idea if any features we want to support have the associated userspace tools in BLFS. It seems to me that would be dmraid, device-mapper, mdadm and lvm2. Am I missing anything?

Replying to dnicholson@linuxfromscratch.org:

We can certainly start simple and build up features over time. I mean, the first step is just to make sure that you could boot from a standard partition and that the process works in the book.

Sounds good to me... ;-)

Question on timing, though: IMO, the full-featured DM/MD/LVM/whatever initramfs would be way too much of a change for a 6.3 book release. Actually, I wonder whether this should all start out as an improved hint. Hmm.

Or, we could do this all in BLFS, and point the user there at the end of LFS if they have special booting needs. That may be preferable if cpio is required.

This might not be a bad idea anyway. There's other stuff we could talk about in BLFS like generating the docbook docs, too.

Are you thinking docs for the mkinitramfs package (if we do one), or docs for yaird?

I was thinking the mkinitramfs package would just have manpages, but maybe a full DocBook setup wouldn't be a bad idea. Something to think about, anyway.

But if the only thing stopping initramfs support in LFS is cpio, then I don't think that should be critical.

It shouldn't be, no. I think getting an initramfs in there is more important than just cpio, though, so if people do have issues with adding it, I'd like a decent workaround. So far, a separate copy of gen_init_cpio isn't a horrible workaround IMO.

(BTW: the change to let gen_init_cpio take its file from stdin is about four lines. I've got a test SVN repo up (read-only without authorization, and no users created yet except me) at https://svn.kdzbn.homelinux.net/svn/lfs-initramfs/. The only issue is that it's hosted on a really-slow DSL connection, and it uses an untrusted cert, so you'll get warned by the svn client. The cert's fingerprint is 41:26:41:7e:16:7f:ba:2d:62:7d:ef:4b:70:6c:4f:76:b7:6c:a1:1b. I still need to make a Makefile and add the other scripts.)