PiOS @ Pi4, after upgrade: only ~5 seconds to unlock

[thomas725]

Hi there!

I've used your project to setup a Pi4 with an encrpyted PiOS system a few months ago, which worked fine until now. Today I've ran apt upgrade and after repairing my initramfs (because the idiot I am and the long timespans in between me doing updates of my servers I've forgot to do it the easy way before rebooting) I now managed to boot my Pi4 again.

But I had to connect a screen to find out why it didn't work initially: Something in the new initramfs timeouts if I don't unlock a few seconds and drops to a shell and prevents the unlock script to boot the system.

So I can still boot if I'm "really fast" at connecting via ssh & entering the keyphrase, but that's a very suboptimal situation, which would prevent me from booting the system from a distance after a power outage or even just rebooting remote if the connection is not perfect enough to allow me to do it fast enough.

Anybody knows how to get rid of this timeout in the initramfs and get back to the previous behaviour (= unlimited time to unlock)?

When I'm not fast enough, the screen reads:

Begin: Running /scripts/local-block ... done.
... [repeats 21 times]
Begin: Running /scripts/local-block ... done.
done.
Gave up waiting for root file system device. Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/mapper/crypt does not exist. Dropping to a shell!

BusyBox v1.30.1 (Debian 1:1.30.1-6+b3) built-in shell (ash)
Enter ´help´ for a list of built-in commands.

(initramfs) _

I can connect to the initramfs Dropbear on port 2222 even after that and enter the passphrase, but the system doesn't boot and the screen's output doesn't change when I do. Dropbear keeps running and can be connected to again, but disconnects immediately.

---

UPDATE: okey, so I found here: https://unix.stackexchange.com/questions/67199/whats-the-point-of-rootwait-rootdelay

rootwait is provided to wait indefinitely. It's not always desirable, for example a system may want to fall back to a different root filesystem if the normal one takes too long to respond.

And on my Pi4:

# cat /proc/cmdline 
coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 video=HDMI-A-1:3840x2160M@30,margin_left=64,margin_right=64,margin_top=64,margin_bottom=64 smsc95xx.macaddr=DC:A6:32:74:F2:8D vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000  console=ttyAMA0,115200 console=tty1 root=/dev/mapper/crypt rootfstype=btrfs rootflags=subvol=subvolumes/linux_root fsck.repair=no rootwait

It seems like it should do that. Somehow it doesn't. No idea why though...

---

UPDATE2: this seems related: https://stackoverflow.com/questions/14806294/linux-kernel-parameter-rootwait-being-ignored

The answer there says:

The rootwait kernel parameter only affects the first stage of boot, while the kernel is waiting for its initial root device. From what you're describing, the kernel has already mounted some sort of root device (either a stub root or an initramfs) and started executing startup scripts, so the rootwait parameter no longer applies -- whatever timeout is firing is specified somewhere else. You'll need to look at the startup scripts that are handling this and modify them appropriately.

So I guess the issue I'm seeing is caused by some startup script modified by the latest updates in PiOS.

---

UPDATE3: found it: /usr/share/initramfs-tools/scripts/local has a function local_device_setup() in lines 45-142, with lines 117-120 breaking out of the waiting loop if more than 30 seconds have elapsed.

I've commented out that if, which gave me back the functionality of the pi4 waiting "forever" on me logging into the initramfs dropbear and supplying the luks keyphrase.

[unixabg]

Greetings, First thank you for the information. I am not sure if this is related to https://github.com/unixabg/cryptmypi/issues/46 which I have left open but have not taken time to examine. Upon next opportunity to examine I will take a closer look at this. When you built image did you use the next-4.x branch? Thanks.

[ViRb3]

I can suggest my fix from https://github.com/ViRb3/pi-encrypted-boot-ssh:

sed -i 's/^TIMEOUT=.*/TIMEOUT=100/g' /usr/share/cryptsetup/initramfs/bin/cryptroot-unlock

Tested on Raspberry Pi OS 11 and Ubuntu 22.04

[xxxcrow]

Any tip on how to change it for a real image? 😁

[unixabg]

@xxxcrow I would just remaster with the information above.

[xxxcrow]

@unixabg can you explain what to do please I bounced of many issues, but this one I can't avoid I'm trying to do encrypted Kali + initramfs WiFi And get the same message as the TC, but in my case it's fresh installed, and it's Kali 🫣