[Bug 473615] Re: cryptsetup init scripts are redundant and can break the boot

[Martin Pitt]

Taking some notes while I review this, thinking aloud.

- Code-wise, the init script(s) and upstart job differ in the sense that
the ones marked as "noearly" are started after  the other ones with the
init script, whereas the order can potentially change with the upstart
job (which only has INITSTATE="init", not two phases). If I read the
upstart jobs correctly, then it could even happen that both the init
script and the upstart job run at the same time?

If the order of cryptdisks-enable.conf vs. rcS.conf isn't enforced by
some other dependency/magic/coincidence, then it already seems bad to
run both. So this speaks in favor of removing the init scripts, even
though it means that users might suddenly see a change in the order of
which encrypted disks are mounted at startup.

- Boot order: /etc/init.d/cryptdisks LSB header says to start after
"raid2 mdadm lvm2 evms". The intention is certainly to catch encrypted
disks on RAID/LVM volumes. "raid2" and "lvm2" aren't provided by any
init script, "evms" is long gone, so we don't need to care about those.
/etc/init.d/mdadm provides "mdadm", but mdadm doesn't have a startup
init script (just an udev rule). Thus, the init script dependencies
intended by the LSB header have never been implemented by our init.d
priorities.

I assume this is what you meant with "So both before and after, this is
racy".

The actual bzr change looks correct to me wrt. its intention. Two small
nitpicks: changelog has an "ad" typo (meaning "and"), and in the dpkg
version the "lt-nl" comparison would suffice (this would fix the corner
case where these symlinks were deliberately created manually before
installation; very pathological, though).

> alternative approach would be to also hook the upstart job into a udev
rule at the same time, to completely eliminate the raciness.

This would mean to run all the parsing, modprobe, dmsetup mknodes, etc.
code each time an ecrypted device gets added (which could be on an USB
key). Semantically this would probably be correct, since these could be
handled in crypttab as well. I'm just not sure about how much overhead
this would introduce for a running session.

So I propose we do this small SRU for now, and test it with various
common setups (encrypted LVM, encrypted root, encrypted root+home,
encrypted home, encrypted swap). In lucid we ought to replace the
upstart job with an udev rule based solution and also clean up the
scriptery around it (much of it looks obsolete, and we still have gems
like "CRYPTDISKS_CHECK=vol_id" in /etc/default/cryptdisks, which is
doomed to fail).

-- 
cryptsetup init scripts are redundant and can break the boot
https://bugs.launchpad.net/bugs/473615
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs at lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs