[Pkg-sysvinit-devel] cryptdisks(-early) initscripts, dependencies and loops

[Jonas Meurer]

Hello,

in the past cryptsetup got several bugreports which complain about the
lsb dependenciy headers specified in cryptdisks and cryptdisks-early
initscipts. (#576646, #575652)

the problem is that loads of possible setups are possible, all
introducing different required initscript order. either another
initscript needs to be invoked before, or after, or between the
cryptdisks-early and cryptdisks initscripts.

to fix some of these issues, cryptsetup contains two initscripts,
cryptdisks-early and cryptdisks. the idea of cryptdisks-early is to be
started before any other device mapping initscript in order to setup
encrypted devices for physical volumes (lvm), software raid source
devices, etc.

cryptdisks runs after all these device mapping initscripts, so it can
setup encrypted devices on top of lvm, evms, software raid, etc.

this adresses at least the most common setups: luks over lvm, lvm over
luks, mdadm-raid over luks, luks over mdadm-raid, luks over lvm over
raid, ...

but as the bugreports manifest, more complex setups do exist, where
the current implementation doesn't work.

in bugreport #576646, the system needs nbd-client to be started before
cryptdisks-early, as nbd-client provides the keyfile for an encrypted
device which itself contains a lvm volume. thus starting nbd-client
between cryptdisks-early and cryptdisks is no option here. on the other
hand nbd-client requires checkfs to be started, which creates a
dependency loop.

other setups might require lvm to be started both before and after
cryptdisks(-early), as some volume group is on top of a encrypted
device, another contains an encrypted device.

another (very common) issue is introduced with encrypted rootfs on top
of lvm (see bugreport #575652). cryptdisks-early and lvm would need to
be stopped after umountroot, which is impossible so far. i added
X-Stop-After headers to cryptdisks(-early) initscripts now in order to
fix at least the initscript stop order for setups without encrypted
root.

to make it short: current dependency based boot system doesn't provide a
solution to this complex issue in my eyes.

so i'm hereby asking for advice how do adress these issues. should i
simply tag the bugs as wontfix, describing that a solution is
impossible? maybe i could write a paragraph for README.Debian, which
describes the problem and encourages users to fix the issue locally,
just as the submitter in bugreport #576646 did.

looking forward to read your comments ...

greetings,
 jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/attachments/20100601/3bb6587d/attachment.pgp>