Your message dated Wed, 04 Mar 2020 00:49:12 +0000
with message-id <[email protected]>
and subject line Bug#933142: fixed in cryptsetup 2:2.3.0-1
has caused the Debian Bug report #933142,
regarding /etc/init.d/cryptdisks force-start no longer ignores noauto
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
933142: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933142
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
Source: cryptsetup
Source-Version: 2:2.3.0-1
Done: Guilhem Moulin <[email protected]>
We believe that the bug you reported is fixed in the latest version of
cryptsetup, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Guilhem Moulin <[email protected]> (supplier of updated cryptsetup package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Wed, 04 Mar 2020 00:48:19 +0100
Source: cryptsetup
Architecture: source
Version: 2:2.3.0-1
Distribution: unstable
Urgency: low
Maintainer: Debian Cryptsetup Team
<[email protected]>
Changed-By: Guilhem Moulin <[email protected]>
Closes: 916649 918008 933142 949623
Changes:
cryptsetup (2:2.3.0-1) unstable; urgency=low
.
* New upstream release, introducing support for BitLocker-compatible
devices (BITLK format) used in Windows systems.
WARNING: crypttab(5) support for these devices is currently *experimental*
and requires blkid from util-linux >=2.33 (i.e., Buster or later). These
devices currently have no keyword to use in the 4th field (unlike 'luks'
or 'plain'), the device type is inferred from the signature instead.
* crypttab(5): Make the 4th field (options) optional so we don't have to
introduce a new keyword for each new device type. (That field is also
optional in the systemd implementation.) Other fields (dm target name,
source device, and key file) remain required.
* Install cryptdisks_{start,stop} bash completion scripts to the right
path/name so they are loaded automatically. This was no longer the case
since 2:1.7.0-1. (Closes: #949623)
* d/*.install: Replace tabs with spaces.
* d/cryptdisks-functions: Fix broken $FORCE_START handling. Since
2:2.0.3-2 the SysV init scripts' "force-start" option was no longer
overriding noauto/noearly. (Closes: #933142)
* Move some functions to d/function from the initramfs hook.
* SysV init scripts: skip devices holding the root FS and/or /usr during the
shutdown phase; these file systems are still mounted at this point so any
attempt to gracefully close the underlying device(s) is bound to fail.
(Closes: #916649, #918008)
* Bump Standards-Version to 4.5.0 (no changes necessary).
Checksums-Sha1:
13a2ef3ede7714314538442326ceb962eb44df4a 2853 cryptsetup_2.3.0-1.dsc
14582633d4a1fa940ff1dbdf84b4c354f358aae7 11152992 cryptsetup_2.3.0.orig.tar.gz
a789a23735e32b78943685550e0683249fecbb9d 113464
cryptsetup_2.3.0-1.debian.tar.xz
5ea2c8c6731887deb625c252c1254b4093f5c3a3 9361
cryptsetup_2.3.0-1_amd64.buildinfo
Checksums-Sha256:
6e45dade64562e0edf7b9b669bbac3cbdb07cdb86576d55b704cf0cb15dd2e69 2853
cryptsetup_2.3.0-1.dsc
02be6c00f5575510bb56f8233279ab044b0be5c6622e17e37dad49cd7c237585 11152992
cryptsetup_2.3.0.orig.tar.gz
e7cad0cf149aa3a1886e1845a3cf1e7be5195174c9557373fd6d29b5ed4cd5c3 113464
cryptsetup_2.3.0-1.debian.tar.xz
1197c3e6af4d9b99edbaf3d43d7ab00f36967b9fb1236fd1e1a42fea6828ce2f 9361
cryptsetup_2.3.0-1_amd64.buildinfo
Files:
194443b7a3baf95d4ae95e3df1f1e282 2853 admin optional cryptsetup_2.3.0-1.dsc
725f10442d7c4d14236f96d2c72e0ded 11152992 admin optional
cryptsetup_2.3.0.orig.tar.gz
7a7d0203d241a9d535e80218efbe1162 113464 admin optional
cryptsetup_2.3.0-1.debian.tar.xz
ea549393dec8090abcce45b4c0d2636c 9361 admin optional
cryptsetup_2.3.0-1_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEERpy6p3b9sfzUdbME05pJnDwhpVIFAl5e7YcACgkQ05pJnDwh
pVJ9ug//YWmqJi2h2difSrBeYJa3WS/HdB8pEP7mE4uEYxIIREPeRjFopAMQVjaB
deFBKv5i6+jXqJyDviBYdhPVokQYEutLz2ZIdmz7sn7zHzN2mD1Qg2x5e51+cZOL
fHPiSvwo428MYWN2j/xMZxxYvxWTu/8x4WGyWeFTXZrtbjc3ou8K/Gkq2ywNTRpT
NEb78neUj1crWpmy9ULqUEvd51D2jo1xax0dPns6bMGznS1dykL+SQkrPKaEKsmU
6/DjzgPkAVhULye46F7HAa32bJtG32NZJIj5uCmSsgW6qf3I7vvaP6cvcuyD9vFj
CAPHuv301ainrI5bJMCywH2zgWQ4FCf30FIuepMJ16PEgoqP1f/MbISVeqPU4UnR
FOEFD8YXrU1BT5zTRDRNWYxrJ3L/NykZDkE6ALknowRks31JtUo/Ot+dT+cJnKwT
D98Ad25aAHScsWWwwixXgGTsq0ApYmxvDp6VmKMd2wJn1xlzw7Vv8v8TpsD3su8s
ZEBt+tLUsWG3o9ewpFS3G28kpitTF/otiW27XFhnJKWKFLhAMGVcStcEIt1bbtPV
WHM7YjR6Q4HZCeKFpLTWz6Pl4K97RC7j60hS82Zb3FbPDR4xgYyQdS4ujs/2d/jg
Kaa6ga4TGX5wK7Hr27nmp3VRXKP+Odt3V0atcA+tb++6YU0Z9lE=
=7Jg6
-----END PGP SIGNATURE-----
--- End Message ---
