Talk:Custom Initramfs

From Gentoo Wiki
Jump to: navigation, search
Note
This is a talk page. Please add newer comments below older ones, and sign your comments using four tildes (~~~~). When adding a new section (at the bottom of the page), please mark it as "open for discussion" by using {{talk|open}} so it will show up in the list of open discussions.

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