I discovered a serious problem after updating KDE Neon. Right now, I tested only on my tablet PCs (3 x Dell 5175).
After Upgrades, the system ask for a reboot (as usual) but KDE Neon doesn’t boot anymore after it applied the updates.
When looking at the efi boot entries, a new Ubuntu entry was added. But that one correspond to nothing on my systems.
More precisely, It look like the boot order AND efi partition was altered to something unusual which block KDE Neon to boot.
Hopefully, I have a full system backup and was able to restore the efi partition. And after changing the boot order in the BIOS, I was able to boot again in KDE Neon.
Reading some historical posts, it look it’s not the first time this behavior happens.
I’ll try to find which of the updates created this problem and I’ll post here if I find the culprit.
drkongl : update to 6.1.4-0zneon+22.04+jammy+releases+build1
Shim-signed : update to 1.51.4+15.8-0ubuntu1
Nota : after restoring to the good efi partition, I discovered strange and unwanted behaviors with the “tablet mode” : when docking back to the keyboard/pad, the keyboard and pad are no more recognized and system frozen. Need to hard reset the tablet PC.
Edit : After a while, and some reboots, the tablet mode seems to work again as expected. need to be monitored.
In my case, I had the chance to had a backup my whole system (Ghost). I do it very often and as soon as I discovered the efi problem I described, I just restored the efi partition. And voilà… everything back to a running system. Hope you have a working backup or try to copy the efi partition from another working system (which run the same OS). Should do the job.
How can an OS (or an upgrade) modify the boot options in BIOS? This should not be allowed normally.
Thanks a lot for sharing your experience with fixing this.
I do not keep a full backup of my system, but hopefully in my case I could just select the other boot option from the boot menu (typing F12, F11, Esc, or Del depending on the motherboard maker~) and it now works again.
This image shows the option I have, and the one that does not work (boot loop) is the “UEFI OS” (currently the default), and the one that works is the “ubuntu” one.
hopefully, in your case, the problem is isolated to the “boot order” in BIOS and is easy to correct.
In my case, I had the same plus the efi partition table which was modified which is more tricky to correct for novices.
BTW, I see I’m not the only one affected by this problems and it should be investigated for future updates.
Something is really weird here. You should have only one efi partion anywhere on a system, even if you boot 5 versions of Linux, BSD and Windows. No software update is going to create an EFI partition, not even grub.
I think the only way that can happen is if you put in a secondary drive that had an existing EFI partition from a previous install. At which point, maybe shim or grub got confused?
Boot order can be effected by the linux-firmware package, as UEFI (Unified Extensible Firmware Interface) is, by design, intended to interact with and “replace” the BIOS, so on occasion, on UEFI sustems, you may find some things changed in the BIOS, like disk labeling. Speaking if which, you are not running Secure Boot, are you?
I tests many distribs and my 3 x Tablet PC are Dell 5175. As many Dell PCs, they have their own method to manage the efi partitions by storing in its table all the efi from all the Linux tests versions (or other OSs) i’ve made. Perhaps, as you said, the BIOS was confused between all these efi entries. But this don’t explain why the efi partition was modified.
BTW, generally and fortunately, I delete all the old efi boot entries in the BIOS after a while.
Because I use to move the tested distribs from PC to PC to verify if all work the same on all the PCs, all my tests are on removable medias (USB key, µSD, USB SSD, …) and have their own efi partitions (and GRUB). The integrated PC storage only contains the Windows efi table. It worked fine until now by using this method.
Nota : I boot my KDE Neon from an µSD card from the Dell 5175 integrated µSD reader. I hope this will not change.
No. It’s not really “dual-boot” by grub since each media has it’s own efi partition. This allow me to move the removable media from unit to unit and choose from the unit BIOS boot menu on which media I boot.
