Kernel version detection is unreliable
As some of you have noticed I went on a long semi-rant about the brokenness of the kernel version/compression detection code. Thanks for everyone for bearing with me @foxboron et al. Here's a proper report with, a little bit more structure to it.
Whenever the kernel version is passed as a file - the default as seen it the presets - the detection can miss fire.
Aarch64 (64 bit arm):
- generate zstd compressed kernel AKA Image.zst
- point to it
mkinitcpio -k .../Image.zst
- look at it choke - if run on x86,
kver
will pick thekver_x86
which will read into the binary and understandably fail - if run on non-x86, kver will pick the
kver_generic
, which will calldetect_compression
- the compression will be correctly detected (zstd), yet we'll use
cat
to try and read the binary
Armv7 machine
- generate gzip compressed kernel aka zImage
- point to it
mkinitcpio -k .../zImage
- look at it choke - if run on x86,
kver
will pick thekver_x86
which will read into the binary and understandably fail - if run on non-x86, kver will pick the
kver_generic
, which will calldetect_compression
- the compression will be incorrectly detected, since the magic is not at the start of the file
To workaround these issues, archlinuxarm has opted for using the explicit version in ALL_kver
- see their aarch64 and armv7 presents. In addition (as hinted above) the detection impedes making mkinitcpio able to generate non-native initrds.
My proposal is to remove the related (and frankly very fragile) code - both compression detection and searching for the version within the binary. Only a kver
which satisfies /usr/lib/modules/$kver
should be deemed valid.
Since there are machines out there which use a file based version (ALL_kver=/boot/vmlinux-linux
) a transition should be put in place.
mkinitcpio side:
- whenever file is used mkinitcpio should produce a loud "WARNING: Using XXX is not supported migrate to YYY"
- decide on deprecation period (eg. 2-3 releases) and mention that in the ^^ warning message
- wait for the D day, remove the respective code
Arch side:
- add Arch news article about ^^
- add package install scriplet to check && warn the respective
/etc/mkinitcpio.d/foo
, and/or - write a hook which to update the preset file
An extra (un)fortunate aside effects is that the "Estimated decompression time" in lsinitcpio can go. In practise that's actually a good idea, since the numbers can be quite misleading. The userspace tool used to provide estimate is often completely different code-base than the in-kernel one - in other words its comparing apples to oranges. One notable exception is zstd which is nearly identical code, but the versions vary greatly.
Assuming people are happy with the idea, I'm more than happy to prepare some patches.
Thanks, for sticking until the end o/