clr-boot-manager icon indicating copy to clipboard operation
clr-boot-manager copied to clipboard

Cannot set the iot-lts2018 kernel as the default kernel

Open gvancuts opened this issue 6 years ago • 5 comments

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
  1. 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.

gvancuts avatar Jan 18 '19 14:01 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.

ikeyd avatar Jan 23 '19 10:01 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.

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.

gvancuts avatar Jan 23 '19 11:01 gvancuts

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

ikeyd avatar Jan 23 '19 11:01 ikeyd

@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.

phmccarty avatar Jan 23 '19 18:01 phmccarty

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

fenrus75 avatar Jan 25 '19 14:01 fenrus75