[pkg-cryptsetup-devel] Bug#933142: /etc/init.d/cryptdisks force-start no longer ignores noauto

Justin Pasher justinp at distribion.com
Fri Jul 26 22:14:53 BST 2019


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



More information about the pkg-cryptsetup-devel mailing list