Bug 476916

Summary:	"intrafms-tools" pkcon, update-grub grabs old kernels.
Product:	[KDE Neon] neon	Reporter:	Lee Berry <berry.whitetiger>
Component:	Packages User Edition	Assignee:	Neon Bugs <neon-bugs>
Status:	REPORTED ---
Severity:	minor	CC:	berry.whitetiger, jr, nate, neon-bugs, sitter
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Neon
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	output old hardwae nothing to do here corrected kernel manaully using console. pkcon jumps back to old version 5.15... current hardware with decommissioned kde.5.26 drive in slot /sdb

Description Lee Berry 2023-11-13 05:13:38 UTC

SUMMARY
***
update-grub "intrafms-tools" grabs the wrong kernel version during "boot recovery."

STEPS TO REPRODUCE
1. Previous OS "5.15.0-87-generic" Neon 5.26 something.
2. Manual install newer release Neon6.2 Plasma user edition. with --microode-update=never. (blacklist conical firmware updates)
3. uname -a produces 6.2.0-35-generic
4. run "apt update " nothing fails but suddenly kernel points to old (kernel)
5. uname -a produces 6.2.0-35-generic however, (initd.ig pointer to 5.15.0.87
6. reboot into ER-mode 6.2.0-35 run clean up.
7. open console cd /boot and remove old kernel-5.15 and "map"
8. close console and run update-grub. Problem reappears see screenshot.
9. copy new image 6.2 to initd.img and vmlinuz using move (mv)
10. delete all references to 5.15, 5.19 etc. except QT.
11. login as normal user-admin
12. run pkcon refresh && pkcon update. (problems is back!) 6.2.0-35-generic is ignored.
13. run uname -a produces 6.2.0-35 but /boot vmlinuz is null (no pointer)

work-around-
1. open console and removed 5.15-generic references /boot & /etc/default/grub/grub.conf
2. copy vmlinuz to pointer vmlinux6.2.0-35.
3, unable to run pkcon update or update-distro, or Discovery without "intitamfs-tools" grabbing hold of an old kernel some where?
4. Current thinking is this maybe a QT-update issue and am looking into to that. However update-grub doesn't work for the new release therefore this bug-report.
6. Possible will flush this OS and move forward to newer kernel 6.5 fresh install. However i expect similar results on older hardware.

OBSERVED RESULT:
installer 6.2 works fine no issue.
cd /boot on sda1 partition not sda.
os Neon5.27 on separate partitions.
users /home on separate partion4.

EXPECTED RESULT
Open console to view vmlinuz pointers and map locations before creating a copy of new OS i.e. backup image.
However pointers to map and OS are point to an older release.
Apt -get update && apt-get upgrade should not grab the older kernels.
pkcon refesh should show new kernel. it doesn't.
pkcon update should grab new kernel. it doesn't.
running 'sudo apt-get purge' or grub-clean up should get rid of old software. it doesn't

SOFTWARE/OS VERSIONS
Windows:
macOS:
Linux/KDE Plasma:
(available in About System)
KDE Plasma Version:
KDE Frameworks Version:
Qt Version:

ADDITIONAL INFORMATION

Comment 1 Lee Berry 2023-11-13 05:19:22 UTC

Created attachment 163102 [details]
output old hardwae nothing to do here

hardware should have no bearing on bug.

Comment 2 Lee Berry 2023-11-13 05:21:13 UTC

Created attachment 163103 [details]
corrected kernel manaully using console.

Manually moving kernel and removing old one. update-grub grabs old kernel.

Comment 3 Lee Berry 2023-11-13 05:23:03 UTC

Created attachment 163104 [details]
pkcon jumps back to old  version 5.15...

didn't expect that. software won't update

Comment 4 Lee Berry 2023-11-17 14:22:37 UTC

User thinks that 'osprober' is picking up old kernel (5.15) from a decommissioned SSD-drive that has KDE5.26 in /boot.  The PC's hardware configuration has the old-disk "sdb1" labeled as /boot with boot flag set in the PC's spare slot.  Removing the hot-swap /sdb drive should solve the problem. However, that is just a workaround. The grub-update should  pick up the newest kernel 6.2.X.X. and recognize that the old kernel is not the current OS.  Removing the boot-flag on /sdb2 is also a temp fix.  This bug is very similar to an old "timeshift" bug that occurred on Manjaro where osprober was picking up copies of previous timeshifts. No time shifts are used here. Their fix was to set a flag to disable osprober in /etc/default/grub to GRUB_DISABLE_OS_PROBER=true. They admitted that it's not a fix. It's ust a work around. Many complains on that site about "grub2-mkconfig" not working well and suggest using an alternate boot loader daemon like "systemd_boot" rather than GRUB2. These are theory only,and have not been tested as the user wants to keep the current KDE5.27 same as out of the box original configuration. 

i.e.Manjaro reference: https://forum.manjaro.org/t/grub-found-non-existent-partitions-and-the-system-stopped-booting/130320/7

Comment 5 Lee Berry 2023-11-17 14:27:08 UTC

Created attachment 163240 [details]
current hardware with decommissioned kde.5.26 drive in slot /sdb

A second /boot drive is on the old SSD that has KDE5.26 with the old kernel 5.15.  This drive is not detected when running the kde 6.2 install and does not get added to the boot menu even though the boot flad is set on /sdb1. Since it's obsolete it shouldn't matter to grub-mkconfig or grub-recovery.

Comment 6 Lee Berry 2023-11-17 14:29:33 UTC

Comment on attachment 163240 [details]
current hardware with decommissioned kde.5.26 drive in slot /sdb

note that 6.2 boot drive is /sda1 but is not labeled.