Talk:Initramfs - make your own

Note
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using ~~~~:

A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC)
: A reply [[User:Sally|Sally]] 11:30, 5 November 2024 (UTC)
:: Your reply ~~~~

They are probably not required with modern DEVTMPFS in the kernel

Talk status

This discussion needs help.
Tip: To get this fixed sooner, use {{Proposal}}.

You MUST have "nod /dev/console" (and "dir /dev") as I explained in User:Pietinger/Tutorials/Initramfs_Overview#Why_do_I_need_an_additional_line_when_using_an_embedded_initramfs_.3F

-- pietinger 14:01, 15 June 2023 (UTC)

I've got mine working with just the /dev dir, and it just mounts a devtmpfs there

This defines the structure my script makes, the mounts are fstab based, and some of the first lines in the init script are it mounting those things

Zen desu (talk) 14:11, 15 June 2023 (UTC)

Do you use a (external) CPIO ? I have a built an embedded initramfs and I have needed this line. (both are explained in my link). -- pietinger 14:24, 15 June 2023 (UTC)

Mine is embedded, I did it like this, using that script i have on github to generate the directory: Full_Disk_Encryption_From_Scratch_Simplified#Embedding_the_initramfs

I've used that method with dracut and with my totally custom ones, mostly so i can sign the whole kernel/initramfs for secure boot. (and have done both with EFI stubs)

Zen desu (talk) 14:28, 15 June 2023 (UTC)

You do embedding with a directory and not with a file-list (as I did). Maybe there is a difference. I only can tell it was necessary to have this line when I did my embedded initramfs with a file-list.

pietinger 14:44, 15 June 2023 (UTC)

Alternate construction methods

I think the current info is helpful, but I prefer the process of embedding the initramfs into the kernel, so it's all one file, and fewer steps. I'm not sure how to go about mixing the info. I think it makes sense for each style to have it's own section, maybe a subpage? this stuff can get really complex and messy, and I think breaking it into a page describing the why/how/what and then pages showing different methods makes more sense.

Maybe there should be a section showing the process of building the initramfs in /usr/src/initramfs, and then a section for using that with cpio or with the kernel build, but i feel it's important to demonstrate that using cpio means it doesn't have to be built in one directory, im not sure why you'd want it to be a separate file, if you want to use the same initramfs across kernels, can't you just have them keep using the same source directory? Maybe that makes sense when using a bootloader, but leaving an archive that can't really be signed sitting around, that controls my boot process, scares me. I also like that there is less variability when combining it all, if a kernel+initramfs image boots, that probably won't break easily. That also helps solve the issue of modules being tied to a kernel version.

Zen desu (talk) 15:28, 16 June 2023 (UTC)

systemd issues

Zen desu has already solved this through ugrd I think, but I just leave this here for posterity in case other ones struggles with systemd/udev stopping during boot and never finishes mounting root when using your own initramfs:

$ cat /etc/udev/rules.d/99-zoverride.rules 
SUBSYSTEM=="block", KERNEL=="dm-0", ENV{SYSTEMD_READY}="1"

It makes systemd think that dm-0 is ready from udev (use e.g. udevadm info --attribute-walk --name=/dev/whatever to find out what name should be if not dm-0). Might be a dirty hack, but I think the alternative is to embed all of udevd in the initramfs.