Add compatibility to package kernel-debs that use a localversion-X file

[pddenhar]

Description

The current kernel.sh build system uses the grab_version() function in utils-compilation.sh to determine the version string of the kernel and locate the build artifacts after make has completed.

grab_version is a simple implementation that parses the makefile to guess the final kernel version, but if a userpatch has been applied to the kernel that includes a localversion-xx file (the PREEMPT_RT patch does this, for example), the returned value will be wrong (grab_version returns 5.10.110 when the true value used to name the vmlinuz image is 5.10.110-rt53-rockchip-rk3588)

Thank you to @rpardini on Discord for helping me identify a fix for this issue.

This patch switches kernel.sh to use the built in make kernelrelease command to return the kernel version, which takes into account any localversion-xx files in the kernel tree, as well as the LOCALVERSION=-${LINUXFAMILY} value appended by the armbian kernel-make.sh code.

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration.

• Compile kernel on current HEAD with localversion-rt file present. Expected result: build failure
  Packaging fails at kernel_package_callback_linux_image() --> lib/functions/compilation/kernel-debs.sh:213
  which is run_host_command_logged ls -la "${kernel_pre_package_path}" "${kernel_image_pre_package_path}"
  This fails because kernel_image_pre_package_path is derived from grab_version
• Compile kernel with this patch and no localverison-rt files:
  vmlinuz filenames are unchanged from current functionality and correctly located by kernel-debs.sh to be built into .deb files.
  Output from run_host_command_logged ls -la "${kernel_pre_package_path}" "${kernel_image_pre_package_path}":

-rw-rw-r-- 1 root root   215715 May 10 19:33 config-5.10.110-rockchip-rk3588
-rw-rw-r-- 1 root root  7779350 May 10 19:33 System.map-5.10.110-rockchip-rk3588
-rw-rw-r-- 1 root root 34013696 May 10 19:33 vmlinuz-5.10.110-rockchip-rk3588

.deb creation is correct:

linux-image-legacy-rockchip-rk3588_23.05.0-trunk--5.10.110-Sad1f-D4008-Pbb66-Cc2a1Hfe66-HK01ba-Vc222-B049d_arm64.deb
linux-headers-legacy-rockchip-rk3588_23.05.0-trunk--5.10.110-Sad1f-D4008-Pbb66-Cc2a1Hfe66-HK01ba-Vc222-B049d_arm64.deb
linux-dtb-legacy-rockchip-rk3588_23.05.0-trunk--5.10.110-Sad1f-D4008-Pbb66-Cc2a1Hfe66-HK01ba-Vc222-B049d_arm64.deb

• Compile kernel with this patch and localverison-rt files:
  vmlinuz files are correctly named with both the localversion-xx file and the armbian localversion appended in kernel-make.sh.
  Output from run_host_command_logged ls -la "${kernel_pre_package_path}" "${kernel_image_pre_package_path}":

-rw-rw-r-- 1 root root   210209 May 10 19:48 config-5.10.110-rt53-rockchip-rk3588
-rw-rw-r-- 1 root root  7777472 May 10 19:48 System.map-5.10.110-rt53-rockchip-rk3588
-rw-rw-r-- 1 root root 33714688 May 10 19:48 vmlinuz-5.10.110-rt53-rockchip-rk3588

.debs are created as expected:

linux-image-legacy-rockchip-rk3588_23.05.0-trunk--5.10.110-Scbae-D4008-Pbb66-C3f61Hfe66-HK01ba-Vc222-B049d_arm64.deb
linux-headers-legacy-rockchip-rk3588_23.05.0-trunk--5.10.110-Scbae-D4008-Pbb66-C3f61Hfe66-HK01ba-Vc222-B049d_arm64.deb
linux-dtb-legacy-rockchip-rk3588_23.05.0-trunk--5.10.110-Scbae-D4008-Pbb66-C3f61Hfe66-HK01ba-Vc222-B049d_arm64.deb

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules

[rpardini]

Thanks @pddenhar -- looks good on first contact -- I will cherry pick this and do a few dozen kernels with this and let you know.

[rpardini]

Hello, I've tried a few kernels. Here's some feedback

• Please only capture the version when you need it (eg, at the top of packaging).
• Please keep version as original, and only change kernel_version_family
  Consider this failure on a legacy kernel: https://paste.next.armbian.com/tozadewuda
  So you cannot assume kernelrelease will always work, and gotta do it as late as possible, and fallback to previous scheme if it fails.

I'm still not sure this is generally the best way forward, though. If we simply rm localversion-* files before building, we'd get the expected version. If you wanna include -rt in the version name, you could simply change LINUXFAMILY to something like meson64-rt (use a hook) -- that would produce much clearer package names too. (package names and versions are calculated before any git is cloned, or patches applied, much less any "make" is run.)

[rpardini]

... review in #5166 (comment) above, sorry ...

[pddenhar]

* Please keep `version` as original, and only change `kernel_version_family`
  Consider this failure on a legacy kernel: https://paste.next.armbian.com/tozadewuda
  So you cannot assume kernelrelease will always work, and gotta do it as late as possible, and fallback to previous scheme if it fails.

Ah, I didn't realize kernelrelease was not something that would work on older kernels. It has been in the Makefile since at least kernel v2.6 so I made the mistake of assuming it would be functional on all practical kernels.

... change LINUXFAMILY to something like meson64-rt (use a hook) -- that would produce much clearer package names too. (package names and versions are calculated before any git is cloned, or patches applied, much less any "make" is run.)

I do think this is a fair point, it would be nice to have package names that reflect whether a given kernel has RT patches applied.

I will take a swing at only using kernelrelease if functional and falling back to grab_version if not.

[rpardini]

Ah, I didn't realize kernelrelease was not something that would work on older kernels. It has been in the Makefile since at least kernel v2.6 so I made the mistake of assuming it would be functional on all practical kernels.

That assumption is sane, yes. It might very well have worked on our ~63-ish kernels...! Unfortunately some of our legacy kernels are insane, and people are really attached to them.

would be nice to have package names that reflect whether a given kernel has RT patches applied.

We could actually create a edge-rt BRANCH for meson64 for example, with the same-ish patches, but a KERNELBRANCH= pointing to a tag, include the -rt patch, and LINUXFAMILY=meson64-rt. In this case just removing ./localversion-* might the simplest working solution.