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
signature.asc
Description: Digital signature
