Talk:Custom Initramfs

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:33, 5 November 2024 (UTC)
:: Your reply ~~~~

Extending this article

Talk status

This discussion is done.

This article used to be the Initramfs article on the (long gone) gentoo-wiki.com. (It was originally created and written and maintained by me. I relicense my text under the CC-BY-SA license.) I finally found the time to overhaul my article and left out the parts that weren't written by me, in particular anything about modules, systemd, bootsplash, telnet, cmdline et cetera. I don't use any of these things, so if you do, and got it working in your personal Custom Initramfs, feel free to extend this article accordingly. But please try to keep things simple. Thank you... Frostschutz (talk) 23:28, 8 January 2014 (UTC)

Isn't there a step missing where you create the sym links to busybox for the various applets? On bumping to busybox-1.23 a lot of people complained that these instructions didn't work and from what I can tell, it was because they hadn't run /bin/busybox --install -s in the chroot. See https://bugs.gentoo.org/show_bug.cgi?id=536988. blueenss.

Thanks for letting me know. Normally, the `busybox --install -s` should not be necessary. Busybox has an option to use its own applets when there is no binary of that name present. And this option used to be enabled by default in Gentoo. I see this is no longer the case, and also several busybox applets were removed (ar, bbconfig, flash*, mkfs.reiser, tune2fs, uncompress...). There was an issue on the bug tracker a while ago where I commented https://bugs.gentoo.org/show_bug.cgi?id=501092#c3 - unfortunately this now seems to have happened, and Gentoo's busybox config is now officially messed up. Frostschutz (talk) 12:58, 22 January 2015 (UTC)

This issue was introduced in sys-apps/busybox-1.22.1-r1, which changed `allyesconfig` to `defconfig` for reasons unknown. Changing it back to `allyesconfig` in the busybox-1.23 ebuild fixes the issue. I also found another bug report https://bugs.gentoo.org/show_bug.cgi?id=526008 Frostschutz (talk) 13:26, 22 January 2015 (UTC)

Ah, found it: https://bugs.gentoo.org/show_bug.cgi?id=525586 - all this for a CONFIG_TFTP_DEBUG=n. Oh well. Frostschutz (talk) 13:43, 22 January 2015 (UTC)

Updated the article so it should work regardless. Also added it to the Troubleshooting section so hopefully users running into this issue will stumble over it somehow. I still hope Gentoo will revert this change but it's not my decision to make. Frostschutz (talk) 15:50, 22 January 2015 (UTC)

Why "back to you?"

Talk status

This discussion is done.

Hi Frostschutz,

I noticed you reverted most of my editing changes to this article. I was curious as to why you reverted the changes. Why "back to you"?

Thanks! --Maffblaster (talk) 18:53, 1 June 2015 (UTC)

Previously discussed here. I tried to get used to it but after two months I still think it's horrible, and I don't think I'm the only one. Frostschutz (talk) 20:47, 1 June 2015 (UTC)

I was a little surprised to see that, but I'm not going to discuss it further. Things don't always have to be the way I prefer. :) You should continue to improve it! It's a good article. See you around! --Maffblaster (talk) 19:09, 2 June 2015 (UTC)

cryptsetup not prompting for password

Talk status

This discussion is done.

I've followed this guide, have the basic bits, devtmpfs, lvm and dm-crypt.

However, cryptsetup never prompts for my password to unlock the key file. There's a point when the boot up appears to hang, but it's just waiting for input as after I type the password in for the key file, it continues on. So, what gives?

What happens if you just hit enter? If a new prompt shows up, maybe the old one just got eaten by kernel messages? You can silence those with `echo 0 > /proc/sys/kernel/printk` before calling cryptsetup (and echo 1 afterwards). Frostschutz (talk) 17:27, 3 July 2016 (UTC)

Yup, I finally noticed that the prompt is printed out a dozen or so lines earlier. I'll give the `echo 0` a go. --TitanOfOld (talk) 13:00, 4 July 2016 (UTC)

And that did the trick nicely. --TitanOfOld (talk) 15:44, 4 July 2016 (UTC)

lddtree secion

Talk status

This discussion is done.

I've got lddtree from the pax-utils installed but mine does not have an option --copy-to-tree. Can someone enlighten me. :) Or can this section be removed? — The preceding unsigned comment was added by StefanLangenmaier (talk • contribs) February 24, 2017‎

Works for me Frostschutz (talk) 16:20, 24 February 2017 (UTC)

   $ lddtree --help
   [...]
   Copying options:
     --copy-to-tree DEST   Copy all files to the specified tree
   [...]
   $ equery belongs $(which lddtree)
    * Searching for /usr/bin/lddtree ... 
   app-misc/pax-utils-1.2.2 (/usr/bin/lddtree)

Thanks Frostschutz for your feedback, I still have the stable version (app-misc/pax-utils-1.1.7) installed, looks like this is a recent feature. — The preceding unsigned comment was added by StefanLangenmaier (talk • contribs) February 25, 2017‎

StefanLangenmaier - Please remember to sign your comments on discussion pages and close the discussion when you're finished. I'll mark this one for you. --Maffblaster (talk) 21:03, 27 February 2017 (UTC)

Gentoo useflags strike again, turns out the --copy-to-tree option requires the python useflag to be enabled. Without this useflag, pax-utils will install a shell script of the same name, which lacks this option. Frostschutz (talk) 10:38, 24 August 2017 (UTC)

Section "Finalizing"

Talk status

This discussion is done as of August-24-2017.

Before rebooting, shouldn't kernel and initramfs get (recompiled in case of built-in and) installed and be efibootmgr'ed to the UEFI firmware respectively made known to classical bootloader?
--Charles17 (talk) 15:51, 7 June 2017 (UTC)

It's mentioned. I should have read more carefully.--Charles17 (talk) 10:27, 24 August 2017 (UTC)

Section "Problems with Init and switch_root"

Talk status

This discussion is done.

I have setup an initramfs, with dropbear ssh and luks on an RPi3. The following command section always seems to hang my device; right at the point of the switch_root.

FILE /usr/src/initramfs/initminimalistic /init example

# Clean up.
umount /proc
umount /sys

# Boot the real thing.
exec switch_root /mnt/root /sbin/init

`man switch_root` says that, "switch_root moves ALREADY MOUNTED /proc, /dev, /sys and /run to newroot". The majority of init examples use umount to clean-up, while the man-page states that switch_root will move the already mounted fs.

I ended up replacing,

root #umount /proc /sys /dev

with

root #mount --move /proc /newroot/proc

root #mount --move /sys /newroot/sys

root #mount --move /dev /newroot/dev

to enable the booting into the encrypted RPi3. Can anyone comment on the prevalence of umount in these init scripts and/or provide some context for me to properly document this workaround? Hrothgar13 (talk) 10:56, 14 December 2017 (UTC)

`man switch_root` says that, but that's not `busybox switch_root` and I don't see those extra moves in busybox switch_root anywhere. The reason for the cleanup is so the "real" init system starts in a clean state. Gentoo's OpenRC mounts these things for you. If you are using a different init system, that expects these to be already mounted, you'll just have to adapt to your needs. Frostschutz (talk) 12:06, 14 December 2017 (UTC)

Thanks Frostschutz for the feedback. FWIW I touched base with Sakaki who authors the image I was using for the RPi3 (Experimental ARM 64-bit) and it appears that the mount --move command is the way they would do it with that particular image. I have added a small section to the troubleshooting section for this variation. Hrothgar13 (talk) 06:39, 24 December 2017 (UTC)

Talk status

This discussion is still ongoing.

The code for moving /proc and so on uses util-linux's mount's syntax. Busybox is, again, different. IIUC the code should be:

root #mount -o move /proc /newroot/proc

root #mount -o move /sys /newroot/sys

root #mount -o move /dev /newroot/dev

Goverp (talk) 11:28, 5 February 2020 (UTC) goverp

Busybox standalone

Talk status

This discussion is still ongoing.

I don't know if this is recent, but the standalone mode of Busybox (i.e. Busybox searching in its own applets instead of searching for a binary) requires the proc FS to be mounted on /proc. So, even in standalone mode, your example cannot work without:

• either creating at least a link for mount and switch_root;
• or keeping proc mounted as long as possible and use the full path to Busybox when not mounted:

FILE /usr/src/initramfs/initminimalistic /init example

#!/bin/busybox sh

# Mount the /proc and /sys filesystems.
/bin/busybox mount -t proc none /proc # Full path needed because proc not mounted
mount -t sysfs none /sys

# Do your stuff here.
echo "This script just mounts and boots the rootfs, nothing else!"

# Mount the root filesystem.
mount -o ro /dev/sda1 /mnt/root

# Clean up.
umount /sys
umount /proc # Unmount proc last

# Boot the real thing.
exec /bin/busybox switch_root /mnt/root /sbin/init # Full path needed because proc not mounted

Stéphane, Gentoo in the Alps (talk) 07:14, 15 July 2020 (UTC)

That's news to me. I'm not actively using Gentoo anymore but I'll have a look at this. In that case there is basically no point to the standalone/applet mode anymore and you just have to run the `/bin/busybox --install -s` (or prepopulate the initramfs with the symlinks). Frostschutz (talk) 09:11, 7 August 2020 (UTC)

Tested, worked for me in a fresh Gentoo amd64 stage3 install, using busybox v1.31.1 and ~amd64 v1.32.0 - applets run fine without symlinked and without /proc mounted. Frostschutz (talk) 18:18, 8 August 2020 (UTC)

Encrypted Keyfile

Talk status

This discussion is still ongoing.

This no longer works for me. There's either some requirements that aren't mentioned which prevent cryptsetup from opening a small image file or the newest cryptsetup (sys-fs/cryptsetup-2.3.4-r1) just can't do it anymore. I always get

root #cryptsetup open --type luks /usr/src/initramfs/root/key.luks lukskey

...
Requested offset is beyond real size of device /usr/src/initramfs/root/key.luks

--Vokiel (talk) 14:16, 11 May 2021 (UTC)

`cryptsetup` defaults to LUKS2 now, which uses very different offsets — 16M of random data by default, which will significantly increase the initramfs size. You can reduce that but then you'll have fewer available keyslots (with --offset 1M, it will be 3 keyslots). Alternatively, it's also possible to just zero out unused keyslot area (allows compression at risk of breaking the LUKS header).

`truncate -s $((2048 * 512 + 512)) key.luks`; `cryptsetup luksFormat --type=luks2 --offset=2048 key.luks`, `WARNING: keyslots area (1015808 bytes) is very small, available LUKS2 keyslot count is very limited.`

Frostschutz (talk) 20:57, 11 May 2021 (UTC)