:: [DNG] cryptsetup-initramfs "Try aga…
Pàgina inicial
Delete this message
Reply to this message
Autor: Alexander Bochmann
Data:  
A: dng
Assumpte: [DNG] cryptsetup-initramfs "Try again later"
Hi -

I've been converting a chimaera setup to an encrypted root file system
with the option to enter the unlock passphrase via dropbear-initramfs.

This almost works, except I'm running into the problem that the
cryptsetup-initramfs script terminates with a "Try again later" message
(unlocking the root fs from the console is still possible).

This problem is being mentioned a few times, but without a real solution,
like here:
http://dev1galaxy.org/viewtopic.php?id=3642
http://maemo.cloud-7.de/irclogs/freenode/_devuan/_devuan.2020-02-09.log.html

As quoted in the dev1galaxy thread, the code that displays "Try again
later" is this, right at the top of cryptsetup-initramfs:

> TABFILE="/cryptroot/crypttab"
> unset -v IFS
>
 > if [ ! -f "$TABFILE" ] || [ "$TABFILE" -ot "/proc/1" ]; then
 >         # Too early, init-top/cryptroot hasn't finished yet
 >         echo "Try again later" >&2
 >         exit 1
 > fi


After some poking around I found the --full-time option in the busybox
ls, and it turns out that $TABFILE is actually a few seconds older than
the /proc/1 directory in the initramfs on my system:

~ # ls -al --full-time /cryptroot/crypttab
-rw-------    1 root     root            75 2022-03-21 00:54:12 +0000 /cryptroot/crypttab
~ # ls -ald --full-time /proc/1
dr-xr-xr-x    9 root     root             0 2022-03-21 00:54:31 +0000 /proc/1


When I then touch /cryptroot/crypttab to update the timestamp, the
script runs successfully...?

Does anyone have an idea why that happens? Is the cryptsetup-initramfs
logic wrong, or did -ot at some point have less resolution and didn't
look at the timestamp seconds?
Is this something Devuan-specific for some reason? Searching the 'net
only finds a small handful of results, and only in relation to Devuan.

Alex.