Talk:Custom Initramfs

Extending this article
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?"
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
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
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‎


 * - 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"
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"
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.

`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,

with

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 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)

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

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

Busybox standalone
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: