clr-boot-manager
clr-boot-manager copied to clipboard
Cannot set the iot-lts2018 kernel as the default kernel
Steps to reproduce this issue:
- Install Clear Linux (I'm currently on 27320)
-
sudo swupd bundle-add kernel-iot-lts2018
- 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
- 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.
You have a core problem in your packaging in that your release number appears to be entirely made up and not suiting RPM specs.
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.
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 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
.
Release: is the build sequence number, and cannot be based on some upstream version thing... I'm fixing the package.