Cannot set the iot-lts2018 kernel as the default kernel

[gvancuts]

Steps to reproduce this issue:

1. Install Clear Linux (I'm currently on 27320)
2. sudo swupd bundle-add kernel-iot-lts2018
3. Check kernels available (note: my system was recently updated so I have two native kernels)

   $ sudo clr-boot-manager list-kernels
   org.clearlinux.iot-lts2018.4.19.13-1901141831
   org.clearlinux.native.4.20.3-683
   org.clearlinux.native.4.19.13-680

4. Try to set the org.clearlinux.iot-lts2018.4.19.13-1901141831 kernel as

   [ERROR] cbm (../src/bootman/bootman.c:L345): No matching kernel in ///usr/lib/kernel, bailing

If you try to set the other native kernel, things work as expected (sudo clr-boot-manager set-kernel org.clearlinux.native.4.19.13-680)

I have slightly instrumented the code with printf in an attempt to troubleshoot this. Here is the patch I have applied to the latest master source:

diff --git a/src/bootman/bootman.c b/src/bootman/bootman.c
index cfc7829..3ca08d9 100644
--- a/src/bootman/bootman.c
+++ b/src/bootman/bootman.c
@@ -313,6 +313,8 @@ bool boot_manager_set_default_kernel(BootManager *self, const Kernel *kernel)

         for (uint16_t i = 0; i < kernels->len; i++) {
                 const Kernel *k = nc_array_get(kernels, i);
+                printf("Type: %s, version: %s, Release: %d\n", kernel->meta.ktype, kernel->meta.version, kernel->meta.release);
+                printf("Type: %s, version: %s, Release: %d\n", k->meta.ktype, k->meta.version, k->meta.release);
                 if (streq(kernel->meta.ktype, k->meta.ktype) &&
                     streq(kernel->meta.version, k->meta.version) &&
                     kernel->meta.release == k->meta.release) {

diff --git a/src/cli/ops/kernels.c b/src/cli/ops/kernels.c
index 66e2648..5bd5054 100644
--- a/src/cli/ops/kernels.c
+++ b/src/cli/ops/kernels.c
@@ -144,6 +144,7 @@ bool cbm_command_set_kernel(int argc, char **argv)
         kern.meta.ktype = type;
         kern.meta.version = version;
         kern.meta.release = release;
+        printf("Release: %d, Kern: %d\n", release, kern.meta.release);

         /* Let CBM take care of the rest */
         if (!boot_manager_set_default_kernel(manager, &kern)) {

With that in the code, here is the output:

$ sudo ./src/clr-boot-manager set-kernel org.clearlinux.iot-lts2018.4.19.13-1901141831
Release: 1901141831, Kern: 1901141831
Type: iot-lts2018, version: 4.19.13, Release: 1901141831
Type: native, version: 4.19.13, Release: 680
Type: iot-lts2018, version: 4.19.13, Release: 1901141831
Type: native, version: 4.20.3, Release: 683
Type: iot-lts2018, version: 4.19.13, Release: 1901141831
Type: iot-lts2018, version: 4.19.13, Release: 8007
[ERROR] cbm (../src/bootman/bootman.c:L324): No matching kernel in ///usr/lib/kernel, bailing

I don't understand at all why k->meta.release does not hold the correct value. Based on the printf outputs, it is parsed correctly from the command-line, the kernel detection function stores the right value in the array. Could nc_array_get possibly corrupt that data? Note that everything works fine with the other native kernels.

[ikeyd]

You have a core problem in your packaging in that your release number appears to be entirely made up and not suiting RPM specs.

[gvancuts]

You have a core problem in your packaging in that your release number appears to be entirely made up and not suiting RPM specs.

Not disagreeing with you on the fundamental that we should use a better release number. For the sake of clarity, it's not random, it's based on the date/time (YYMMDDHHMM): https://github.com/clearlinux-pkgs/linux-iot-lts2018/blob/master/linux-iot-lts2018.spec#L18-L20

I think that release number matches the tag that is used in the upstream repo: https://github.com/intel/linux-intel-lts/tags

@miguelinux should be able to provide further details.

[ikeyd]

Yeah looking again there I think that should be part of the version field tbqh. Our packages define our releases, upstream defines their versions.

[phmccarty]

@ikeyd I agree. In Clear Linux OS, the Release field only has significance for the distro as an artifact of building and publishing rpms for every package. All bits needed to represent the upstream package version should be the value of Version.

[fenrus75]

Release: is the build sequence number, and cannot be based on some upstream version thing... I'm fixing the package.