(Bcc:'ed to debian-boot@) On 10/12/2022 16:27, Bastian Blank wrote: > Our documented, I think, policy is, that we don't support loading new > modules into an old kernel within the same ABI. This forces a reboot > after kernel installation. > > However in a lot of cases this just worked. You could update the kernel > package and continue loading most modules. > > Now we have BTF support enabled, which trashes this compatibility > mostly, as it requires a way more strict match between kernel image and > modules.
One thing to note here is Debian Installer netboot images. Those built with a certain kernel-image-$ABI-di can download *-modules-$ABI-di udebs for that ABI at installation-time, but don't check the actual version. They do display an error if the archive doesn't have modules for that ABI name. I recently encountered this incompatibility with a slightly out-of-date custom netboot image I was testing, and it's not really visible to a user that this has happened. It complained about kernel not supporting RAID and so on, then inexplicably failed after partitioning (looked like it couldn't mount root as ext4). I needed to build a new image. > We need to fix that somehow. Options are as far as I see > - remove BTF from modules, > - allow to load modules even on BTF mismatch, or > - reinforce that a user can't do that. I fear I'm being ignorant here, but 'Bump ABI on every build' sounds to me like it would be technically valid. Although, that might defeat the purpose of tracking ABIs, is that the reason it's not an option? > If we go with the last option we would have also some direct advantages. > We could stop signing modules with the secure boot key, but use a > temporary key. This would for a system with signature checking enabled > effectively trash all possibilities to load modules for a different > kernel build. Anyway, I guess it would be possible to modify d-i to check modules more strictly, by using package version instead of ABI name (in src:anna ?).
