As described here on my Librem13v4 with my kernel parameters the actual kernel doesn’t start.
Because of that I wanted to change the kernel used in “Default Boot” to the older one which I can select and start from the boot menu.
When I select the kernel in heads boot menu I get a selection whether I’d like to start the kernel or make it the default boot kernel.
When I select the latter I’m requested to provide my LibremKey to sign the change, I have to enter my PIN and after that heads starts immediately a kernel - the newest kernel that doesn’t work and hangs after kexec.
When I then reboot the broken kernel is still default kernel and I can’t “Default Boot”.
I uninstalled the broken kernel and by doing so could have the older kernel as my “Default Boot” kernel, but uninstalling the newest kernel uninstalls also the meta package needed for kernel updates.
Any suggestion how to change the kernel for “Default Boot”? If needed I could take pictures of the process…
I just tried to reproduce this on my 13v4 with PureBoot beta-9 and PureOS, and had no problem changing the default kernel to an older one. It booted the older kernel immediately after I confirmed changing the default, and the older kernel was the default on the subsequent boot.
are you running an older build of PureBoot by chance? sudo dmidecode -s bios-version
will tell you what version you’re running
Thanks for the command! Yesterday I was looking for a way to find out which is the current coreboot version and which version is installed on my notebook. I found “Confirming the presence of the correct coreboot image” here as a source of information and the way described there does not work (anymore?). Maybe that needs to be updated?
Also I downloaded a new coreboot_util.sh and looked at it, even ran it to get the actual version. But in the end I didn’t find a way to compare the downloaded version to my installed one. Maybe it has been to late at night…
But still neither the current PureOS kernel nor the current Debian Buster kernel do start. Still hangs on kexec -e without any error message. Only kernel and initrd working so far is 4.19.0-2.
BTW: I tried to start the working (old) kernel without --initrd in the kexec command to load it and it looked quiet the same as my attempts to start the newer kernels… Onyl difference: ctrl-alt-del does not work, but works when I try to start a newer kernels from the menu or including --initrd in the kexec command to load.
I followed this thought a bit more and looked at the initrd-files in /boot. I found that the one for the working older kernel is bigger than the ones for the newer not working kernels. I compared the content of the working kernels initrd file /boot/initrd.img-4.19.0-2-amd64 to a newly generated initrd-file for the same kernel and found that there is a lot of difference.
Some of it obviously was related to use and initialization of the gpu and acpi. Also files for plymouth were missing. I remembered that I purged plymouth, because I’m not using a graphical boot screen and have the (bad?) habit of deleting software that I think I do not use.
I installed plymouth and related packages and tried again and the difference related to gpu and acpi not existed anymore.
Yes, I can now start my Librem13v4 with the actual kernel (and the Debian kernel 4.19.0-6-amd64 worked also. Both with newly generated initrd-files.
I’d suspect that there is somewhere a dependency on plymouth is missing. If this is related to the use of PureBoot/coreboot the (meta) package containing the dependency for PureBoot is missing (could also help with documentation issues: containing files in /usr/share/doc/ and could provide the current coreboot_util.sh).
So which part of the boot process does depend on plymouth?
To get back to the original topic: Heads: Can’t change kernel to default boot
This problem seems to arise when the current default kernel is not bootable for some reason.
As shown in the screenshots coreboot/heads let me give the pin for my LibremKey to sign the change for the default boot kernel and then immediately tries to start the former default kernel with no success.
My guess would be that the information is not written except the kernel that is supposed to start after signing is working.
That would mean:
Probably the information about the change of default kernel and the signing should be stored before the kexec
The kexec should load and exec the changed default kernel
it is. I’m looking thru the code and I don’t see how the currently-set default kernel being bootable or not would have any influence on the outcome of setting a new default.
I’m also not seeing any issues booting 4.19.0-5, or any other 4.19.0-x kernels
It’s been the initrd-files that were not usable which resulted somehow from me deinstalling plymouth. The kernel version did nothing have to do with it.
I guess to reproduce you could just deinstall plymouth and rebuild the initrd-file for the default kernel.
