>=sys-kernel/dracut-102 breaks LVM LUKS cryptsetup boot On a KVM/Qemu VM i can capture the following error: [ 1.239849] dracut-initqueue[418]: Failed to start systemd-cryptsetup@luks\x2dcde09b75\x2dd8f7\x2d4be0\x2d88ff\x2deb9c7f36327f.service: Unit systemd-cryptsetup@luks\x2dcde09b75\x2dd8f7\x2d4be0\x2d88ff\x2deb9c7f36327f.service not found. dracut-103-r2 is broken as well. dracut-101 works without change of any config files. There seems to be an upstream issue filed (see https://github.com/dracut-ng/dracut-ng/issues/451). I have added a comment attached my configs.
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.
News item for review: https://public-inbox.gentoo.org/gentoo-dev/20240806170818.1537148-1-floppym@gentoo.org/T/#u
As to your previous comment about "doing this once"- it's your call (you maintain this) if you wish to even do this. My suggestions are just that; keep in mind I already fixed the issue for myself, the suggestion is for anyone else affected and precluding users asking "wtf?". If you think it's not worth it, don't add it. (In reply to Mike Gilbert from comment #26) > News item for review: > > https://public-inbox.gentoo.org/gentoo-dev/20240806170818.1537148-1- > floppym@gentoo.org/T/#u From your text: > +Users who use the "dracutmodules" config option to explicitly name all > +modules to be included may be ^^^ The phrasing on that I'm not sure about. My reading of it- and yes, as Sam pointed out, I can be blindingly literal to a fault- is it's informing the end user they must enumerate *all modules that are used*. That would include the dependencies, which isn't the case. Dependencines don't have to be specified- dracutmodules is the emerge equivalent of @world. I grok you likely know that, I'm just not sure what a better phrasing is there, or if one is needed. One other thing to consider for that text- you're directing users at add_dracutmodules. That's for non hostonly; force_add_dracutmodules is for hostonly. Is it worth mentioning this, or is that getting too far into the god awful mess that is dracut configuration?
My gut tells me that very few users ever touch dracut.conf, and fewer still will be affected by this issue. I don’t personally feel it is worthy of a news item but I have no way to verify my gut check.
(In reply to Mike Gilbert from comment #28) > My gut tells me that very few users ever touch dracut.conf, and fewer still > will be affected by this issue. I don’t personally feel it is worthy of a > news item but I have no way to verify my gut check. Your call, I'm not here to force a hand. This ticket documents the "fix" anyways.
Thanks for considering a news item. If we do a cost vs benefit calculation, maybe the cost at the moment only boils down to another 30 days delay. But maybe that could even be shorter. The benefit is unknown but it could pay off, even for users of other distros where the upstream docs do not cover the problem in the detail found here.
Thanks for making me aware with the news item.
i would be affected by this issue, cuz i am using whole disk encryption and systemd, and i am getting conflicted statements here, should add anything to dracut.conf? should i add module systemd-cryptsetup to my conf or should i just wait, getting a big confused and would liketo boot my system up,
If you have not modified dracut.conf, you do not need to do anything.
i did add omit_drivers="nouveau" and there is nothing else
(In reply to picarica from comment #34) > i did add omit_drivers="nouveau" and there is nothing else Based on that statement, you will be be fine since you're using dracut's autodetection. The people impacted are the ones who are disabling autodetection and specifying the necessary modules themselves (whether intentionally or accidentally).
Closing this as UPSTREAM. Thanks for the patience and feedback.
