Email or username:

Password:

Forgot your password?
Top-level
bse

@pid_eins @vurpo I would assume you also have to pin /lib/modules, or better get rid of that relic completely and move modules inside the UKI?

6 comments
Lennart Poettering

@bse @vurpo kernel modules are pinned by the kernel's version number, i.e. looked for in /usr/lib/modules/`uname -r`/.

bse

@pid_eins @vurpo Yes, but what happens if you install a faulty out-of-tree module that gets built for all existing kernel versions, for example via dkms, and put into /lib/modules/*/?

Lars Marowsky-Brée 😷

@bse @pid_eins @vurpo openSUSE with snapper can reboot into a full older snapshot of the system (except user data), which has saved my butt a few times.

Gabe

@bse @pid_eins @vurpo If you deliberately bypass the system integrity and safety features, then they won't save you. It doesn't matter what those features are.

If you blindly sign initrds, checking won't help you. If you blindly mark a boot config as good, or if you replace your rollback image, or whatever...

The system won't save you from yourself infallibly. You'll still want staging, and monitoring, and disaster recovery.

Lennart Poettering

@bse @vurpo dkms really should synthesize separate menu items for its rebuilds. If it doesnt, it's simply broken and should be fixed.

bse

@pid_eins @vurpo Since both entries would be using the same kernel and hence use the same /lib/modules/$(uname -r)/, you need a mechanism to have multiple versions of your modules folder. If you're serious about preventing older boot entries from breaking retroactively, i think full system snapshots are the only option. Short of that, there might be some compromises like bundling a kernel and all modules, which of course does not protect userspace, but might be easier for commonly used distros.

Go Up