Package: cryptsetup
Version: 2:2.1.0-5
Upon upgrading from Stretch to Buster, I've noticed that the SysV init
script for starting LUKS encrypted partitions (/etc/init.d/cryptdisks)
can no longer be forced to start disks that have the "noauto" option
set, even when using the force-start command. I'm using sysvinit-core
and not systemd.
For example, /etc/crypttab has this:
encdata /dev/xvdb none luks,noearly,noauto
I'm purposely using the noauto option to keep the boot up process from
automatically trying to unlock the partition and waiting for a password.
In Stretch, if I manually run "/etc/init.d/cryptdisks force-start", it
would bypass the noauto option and (as the command implies) force
cryptsetup to attempt to unlock the partition. In Buster, when using the
force-start option, it won't attempt to unlock the partition if it has
the noauto option set.
I've looked at the two key files used by the init script
(/lib/cryptsetup/cryptdisks-functions and /lib/cryptsetup/functions),
and based upon what I can see, the FORCE_START option that's set by the
init script basically becomes useless with the way the logic is
currently defined. The only thing it seems to do is decide whether the
word "ignored" is displayed; it doesn't change the logic flow. The lines
in question are below (I included the logic for the noearly, since it
suffers the same problem):
------------------------------
if [ -n "${CRYPTTAB_OPTION_noearly+x}" ] && [ "$INITSTATE" = "early" ]; then
[ -z "${FORCE_START-}" ] || device_msg "ignored"
return 0
fi
if [ -n "${CRYPTTAB_OPTION_noauto+x}" ] && [ "$INITSTATE" != "manual" ];
then
[ -z "${FORCE_START-}" ] || device_msg "ignored"
return 0
fi
------------------------------
These are the only code blocks that reference FORCE_START, and as you
can see, all it does is change the displayed message. Unless I'm missing
something, how it decides to display the message seems backwards to me
too (it does "show this message when FORCE_START is set", versus "show
this message when the script is executed normally and we find noauto or
noearly").
When trying to understand how $INITSTATE is ever anything but "early" or
"remaining" (as set by the init scripts), I found the
/sbin/cryptdisks_start script. Running that script allows you to unlock
a specific encrypted partition, but not all (without some manual
scripting to read through /etc/crypttab).
Basically, I see two possible solutions:
* Running "/etc/init.d/cryptstart force-start" should ALWAYS try to
unlock a partition, even if it has noearly or noauto set (like it did in
Stretch).
* /sbin/cryptdisks_start must be used when trying to unlock partitions
that use noauto or noearly and I have to write a script to loop through
all encrypted partitions to pass as a parameter.
The first option seems most logical to me, as that's what "force-start"
means to me. That's the way it worked in Stretch (and maybe even
Jessie). Otherwise, what's the point of having force-start?
--
Justin Pasher
