kernel >=7.0.1 dropbear issue

[u/Individual_Range_894]

Hi everyone,

does anyone else have issues with dropbear or clevis since kernel 7.0.1?
My system does not initialize the network adapter anymore. As a result, I can't unlock my encrypted root via ssh or automatically via clevis.

Everything worked fine until the 7.0.1 drop, but I can't figure out what changed, since. I can still build initramfs for 7.0.0 and older, update the grub config and those kernels still boot fine, so I believe nothing is wrong with my kernel config or grub config per se.

On thing I'm confident is that the network interface does not even come up and so the 'network hooks' do not get applied.

Edit: Dracut version 111 (https://github.com/dracut-ng/dracut) released 4 days ago did fix the issue.

Edit 2: there is a gentoo news around dracut v111 (2026-05-08-dracut-hostonly-cmdline) and this version is now in portage available (still unstable right now).

[u/Individual_Range_894]

I analysed the boot log and it might be a boot order issue.
The following log line is missing on newer kernels:

```
systemd[1]: clevis-luks-askpass.path: Got triggered by '/run/systemd/ask-password'.
```
So it might either be a systemd issue with the boot order or a dracut issue. I will investigate further. However its interessting that in 16h nobody else has this issue

[u/Fenguepay → u/Individual_Range_894]

that issue was literally linked in the repo i posted...

please don't use dropbear and expect a "secure system" though

welcome to dealing with dracut though, the creator abandoned it so you're left with me (the person who hates it enough to make something better)

[u/Individual_Range_894 → u/Fenguepay]

that issue was literally linked in the repo i posted...

where? The issue that all kernels before 7.0.1. did work and it is only broken now, is no issue I found in the dracut GitHub issue tracker. Could you please point me to the issue you think is at play, please.

please don't use dropbear and expect a "secure system" though

I read your message already. Still not my current issue.

welcome to dealing with dracut though, the creator abandoned it so you're left with me (the person who hates it enough to make something better)

What's your alternative? I'm open to new, battle tested, hyper secure alternatives 😏

[u/Fenguepay → u/Individual_Range_894]

dracut is not entirely abandoned, it was forked and has new maintainers. this module you want to use seems to be more or less unmaintained though (no updates in years) https://github.com/dracut-crypt-ssh/dracut-crypt-ssh/tree/master

part of the concern is that "modern" dracut is built with systemd as the clear priority so if you're not using that or modules that are designed to work directly with systemd, you're going to be dealing with bugs eventually (as seen here)

there is an open issue similar to the bug you're hitting.

ugrd (my project) is designed to be secure and I took a swing at making a similar ssh module and like the warning mentions, there is not a good way to store keys for SSH. the way this is structured, it's basically telnet+, you can't make guarantees about security unless you totally trust wherever the system is remotely hosted. If you trust the environment that much, you may as well leave plaintext keys around and skip the "interactive" parts of this process, or "just" use the TPM for unattended booting

If it's remotely hosted (and on a "real" server), the simplest option is to use the board's management system or IPMI to get a remote console. This is a more generic method and doesn't pretend to be more secure than it is.

ugrd does have an (experimental) ssh module which should kinda just work and uses openssh but similar to the mentioned module, there are no automated tests (and generally better ways) so you've got the operate under the understanding that you're using something that may break on any update.

there is also the concern with static/dynamic IPs in the pre boot environment, depending on your setup, you may reliably get the same IP, but you have to account for this, and using a static IP in this case may be preferable. I'm guessing that is not a concern since you've been doing this, but that is one thing that can "work until it doesn't" with this type of setup as well