04-02-2024, 12:20 PM
Hi!
I stumbled upon this post...
The bug is still present in Linux Lite 6.6.
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
I stumbled upon this post...
The bug is still present in Linux Lite 6.6.
(08-22-2022, 03:31 AM)Jerry link Wrote: 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
"It's easy to die for an idea. It's way harder TO LIVE for your idea!"
Current Machine:
Dell Precision T1700, 16 GB RAM, SSD Kingston A400, 480 GB.
Laptop:
ASUS X200MA , Intel® Celeron® N2830, 2 GB RAM, SSD Kingston A400, 480 GB.
Current Machine:
Dell Precision T1700, 16 GB RAM, SSD Kingston A400, 480 GB.
Laptop:
ASUS X200MA , Intel® Celeron® N2830, 2 GB RAM, SSD Kingston A400, 480 GB.