Linux Lite Forums
General => Security & Bug Fixes => Topic started by: deejay on June 09, 2022, 04:11:20 PM
-
Not sure if I've posted in the right place but I've got a LT bug with the Kernel Remover command. It keeps coming back with linux-image 5-15.0-33-generic after every time. Attached screenshot.
-
We don't open zip files here for images, please see here -https://www.linuxliteos.com/forums/introductions/forum-posting-guidelines/
-
Apologies for that. Here is the text version of LT info box:
Kernel Remover: For each kernel version to remove, select its:
headers
image image-extra firmware (if any)
The removal process will not begin until your selection is reviewed and confirmed.
Select Kernels available for removal
linux-image-5.15.0-33-generic
Recap: This repeats every time Lite Tweaks is used and the Kernel remover box is ticked. It's always this kernel.
-
Use this command:
sudo apt-mark hold linux-image-unsigned*
pretty sure that package is not needed, but it is causing the trouble.
It's too risky to integrate into Lite Patch. All the experts online advise against it so it will have to wait for 6.2 ISO release. I should be able to include this fix in the 6.2 Lite Upgrade package. Topic stickied.
-
Ok, many tnx.
-
Thank you :)
-
Hi Jerry
Run the sudo apt command as per your instructions and has made no difference. Not really a problem but thought you should know.
Many tnx.
-
Thank you :)
Hi, Jerry! :)
It seems weird to me and as it looks, it is machine dependent.
On the machine I use (Dell Precision T1700), I removed all the kernels previously to the current without having this kind of annoyance.
It is very difficult to me to figure out how this is a Linux Lite bug, since it worked on my machine all the time.
I used this feature from the beginning because I found it handy, but mostly, because it always worked. My current kernel is 5.15.0.46, and the Kernel Remover says nothing about any other kernels.
In a previous answer, you pointed to "linux-image-unsigned". I never skipped this package when Kernel Remover listed it so, maybe this might be the cause that triggered some weird dependencies that prevent the removal of the said kernel version (5.15.0-33).
Now, as far as my understanding goes, this can only be an user error otherwise, I was supposed to get the same error long ago already and this never happened so far.
However, I used synaptic many times to remove kernel packages so, if this still keeps appearing, the other approach is listing all kernel packages with Synaptic, then marking the ones that belong to the older versions than remove all those remainders.
For someone less experienced with Synaptic, this is risky, I know, but it is a way to get the job done.
While I was testing kernels that were downloaded from Kernel.org (way ahead from the standard distro release), I installed and removed many kernels using this procedure and I never had trouble. All it takes is a little extra-caution regarding the running kernel version packages.
As of today, the running version is 5.15.0.46. This means that all the other kernel packages can be removed using Synaptic.
Maybe if I'll make a short screencast, will be of some help.
Best regards! :)
-
I was able to replicate the bug. It will be fixed in 6.2
Sent from my Mobile phone using Tapatalk
-
Hi!
I stumbled upon this post...
The bug is still present in Linux Lite 6.6.
I was able to replicate the bug. It will be fixed in 6.2
Sent from my Mobile phone using Tapatalk
After some digging, I discovered that the problem resides somewhere in the GRUB config files.
For some reason, a reference to the first kernel still remains and it looks like that even if I remove the files manually, that reference restores the files or at least keeps some hidden reference that leads to the listing of the file în the Kernel Remover window.
Viewing the GRUB files, it looks like there still is a reference to that kernel.
Since my programming skills and my understanding are below the requirements to solve the problem, I quit the idea of finding a solution.
Still, I belive that somewhere along the path of the removal, an error message related to the file removal gets skipped and prevents the removal routine to actually remove the files.
The other possibility would be that the GRUB rewriting routine hangs somewhere and skips rewriting the GRUB file or files.
It is also possible to be a combination of both.
At first glance, I thought that since we're dealing with the boot loader, I need to reboot in order to make active the new config files.
I did it repeatedly, including cold boot but still nothing.
This weird thing, appears only if a second removal task is issued.
After the first removal task gets finished, things look like it's done.
After retriggering the removal routine second (third, fourth...) time still, the file(s) gets listed again and so on.
I've done it already many times so why does this happen, it's a mystery. At least to me...
From my modest programming experience, this behaviour occures only if a line of code encounters an unlisted (unknown) error. In this case, next line is skipped or even an entire set of lines.
Usually if I was in a procedure, the procedure was exited due to the unknown error. Next procedure might be another than the required one and the program goes sideways, without any warning/error message.
The only way to go beyond this, is to issue a registry dump, sent data into a file then check each registry entry. ...And I lack the knowledge/practice to get involved at this level.
Can there be some stack overflow? Possibly.
Variable type mismatch, is also possible. Pointer cast operation... Too many possibilities for me to grasp someting out of it.
Best regards, Șerban