| Summary: | >=sys-kernel/dracut-102 breaks LVM LUKS cryptsetup boot with systemd | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Stefan Trenker <strenker> |
| Component: | Current packages | Assignee: | Alexander Tsoy <alexander> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | andrewammerlaan, floppym, henning, renegart, strenker |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| See Also: |
https://github.com/dracut-ng/dracut-ng/issues/451 https://bugs.gentoo.org/show_bug.cgi?id=933995 https://github.com/dracut-ng/dracut-ng/pull/262 https://github.com/dracut-ng/dracut-ng/issues/563 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 937336 | ||
| Attachments: |
emerge --info
dracut.conf /etc/kernel/install.conf make install w/ dracut-101 make install w/ dracut-102 blkid lsblk -f |
||
|
Description
Stefan Trenker
2024-08-04 18:10:29 UTC
Created attachment 899005 [details]
emerge --info
Created attachment 899006 [details]
dracut.conf
Created attachment 899007 [details]
/etc/kernel/install.conf
Created attachment 899008 [details]
make install w/ dracut-101
Created attachment 899009 [details]
make install w/ dracut-102
Created attachment 899010 [details]
blkid
Created attachment 899011 [details]
lsblk -f
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5cf9bf27e76c0afa977c6c6e3938f4408839c003 commit 5cf9bf27e76c0afa977c6c6e3938f4408839c003 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2024-08-04 20:35:36 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2024-08-04 20:35:36 +0000 sys-kernel/dracut: destabilize 102 Bug: https://bugs.gentoo.org/937326 Signed-off-by: Mike Gilbert <floppym@gentoo.org> sys-kernel/dracut/dracut-102.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Filed a dedicated issue for dracut-ng: https://github.com/dracut-ng/dracut-ng/issues/563 This seems to be only relevant for systemd users, can not repro on an openrc system. I mentioned it in upstream; the workaround is to add systemd-cryptsetup to the forced modules. The problem is due to systemd-cryptsetup-generator not being included, thus the logs complaining about systemd-cryptsetup@ not existing. 102 && 103 are effected by this, and yep, it's systemd specific. This should be marked confirmed; see https://github.com/dracut-ng/dracut-ng/commit/649e37bcd5ac46d5ac440b80297370c07ee7e1a8#diff-21b628d9fbf356aea5880a99b83b460c057ae0f064df37a58ca82c2cd8b34830L166-L178 for where this was broken. Upstream hasn't confirmed if they consider this a regression or what, and unfortunately adding backwards compatibility so 'crypt' includes 'systemd-cryptsetup' induces a cycle. I don't know how to fix this quickly iow. (We don't generally bother with UNCONFIRMED vs CONFIRMED in Gentoo, fwiw.) (In reply to Brian Harring from comment #11) > I mentioned it in upstream; the workaround is to add systemd-cryptsetup to > the forced modules. The problem is due to systemd-cryptsetup-generator not > being included, thus the logs complaining about systemd-cryptsetup@ not > existing. I can confirm that adding systemd-cryptsetup to the dracut module list fixes the issue and is a feasible workaround. I have tested this workaround with 102 and 103. It is good for both. Nevertheless i expect dracut to figure out by itself, which systemd-modules it requires to unlock an encrypted disk as it did until 101. To leave this with the user by surprise is not a good idea. So i am still hoping for an upstream fix. Is it fair to say that this is only a problem for people who have explicitly named the modules they want to include via the dracutmodules option? Based on the check() function, I suspect the module would be automatically included if dracutmodules is unspecified, and this is the behavior I see on my own system. I thinks this commenter has the right idea: https://github.com/dracut-ng/dracut-ng/issues/563#issuecomment-2268966884 The dracut.conf man page even warns against using dracutmodules: dracutmodules+=" <dracut modules> " Specify a space-separated list of dracut modules to call when building the initramfs. Modules are located in /usr/lib/dracut/modules.d. This option forces dracut to only include the specified dracut modules. In most cases the "add_dracutmodules" option is what you want to use. (In reply to Stefan Trenker from comment #13) > Nevertheless i expect dracut to figure out by itself, which systemd-modules > it requires to unlock an encrypted disk as it did until 101. To leave this > with the user by surprise is not a good idea. I don't think dracut was doing what you think it was doing. It was not bringing in modules based on your disk config; it only does that when you enable hostonly mode. Instead, dracut is including exactly the modules you have specified via dracutmodules. By happy coincidence, that set of modules just happened to be the set you needed to boot with older versions of dracut. Hmm, upon further inspection I see that you do have the hostonly option enabled. So yeah, I guess this probably is a bug. Indeed it is a misconfiguration on my side. When I started using dracut before around 3 years i was happy to create a configuration which booted my laptop. I googled a lot and was not aware of the subtleties of dracuts configuration elements and differences between add_something and something. In the last 24 hours i learned more about dracut configuration than in the 3 years before. Adding modules with add_dracutmodules is sufficient and systemd-cryptsetup must not be added explicitly. I apologize for all the mess i caused. I would like to give it a week to see if upstream devs provide any feedback. If not, I will resume stabilization of dracut-103. Sound ok? (In reply to Mike Gilbert from comment #18) > I would like to give it a week to see if upstream devs provide any feedback. > If not, I will resume stabilization of dracut-103. > > Sound ok? Sounds pretty ok! Maybe an enews entry could be added before stable. If we can pinpoint which config-option caused the problem and sum things up in a few sentences. On the other hand an enews might qualify as a change which would delay stable. > Maybe an enews entry could be added before stable. If we can pinpoint which config-option caused the problem and sum things up in a few sentences. On the other hand an enews might qualify as a change which would delay stable.
Personally I'm fine w/ this option; this change caught me by surprised because the upstream release notes for 102 don't explicitly state that 'crypt' no longer suffices. They define the "move all systemd-cryptsetup out" as a "performance" change, which it isn't.
Well, the problem only occurs for people setting dracutmodules, which the documentation advises against. I suppose we could do a news item warning people not to do that. (In reply to Mike Gilbert from comment #22) > I suppose we could do a news item warning people not to do that. ...rather than warning people that upstream broke historical compatibility for the crypt module- a critical module- and didn't note it in their release notes? There's definitely some users using dracutmodules out of ignorance; I'm not one of them, and I watch upstream release notes as part of that responsabilité. :) If you want to remind folks "use add_dracutmodules" go for it; but advocating people redo their configs to fix upstream breaking something is a bit heavy handed. Tell them how to work around it, then suggest how you think they should do things. I think it's obvious that any such news item would mention the breakage and what happened. (In reply to Brian Harring from comment #23) I don't think upstream is writing their release notes with your case in mind. I am willing to do a news item about this *once*, but not every time upstream makes a change that you think is under-documented in the release notes. That is a problem you will need to work out with upstream. |
