Description of problem: Need to work differently than on a normal install. I note rok is installed on Mageia 10 alpha Live When Live is used without persistence partition, rok is useless but does not harm. When Live is used with persistence, rok may cause problems if it operates like an a installed system. Live can only boot either original kernel or the latest installed one (regardless of version) So if rok should be used on Live it should uninstall any kernel between the original and the latest installed one, regardless of kernel series and version. (It must NEVER uninstall original (eldest) kernel, and any kernel except that and the latest installed one are completely superfluous as there is no way to select them for booting.) A complicating issue is that the Live installer installs a copy of the Live system to target system, and there rok need to operate like it normally does. So it must not be a special version of rok, and not a special configuration file -it must sense if the system is booted as a live system (with persistence) or as n installed system.
Setting as critical as original kernel must never be uninstalled. I note rok is included in 10alpha1_r2 (to be official) Live. Normally rok ininstalls elder kernels when there are more than 3. We will probably change to have 6.18 as default kernel series and when rok is fixed to handle 6.18, this bug will come in effect. I tried: on 10alpha1 Live Plasma with persistence installed kernel 6.18, then removed original kernel using drakrpm: it could still boot original 6.12 up to desktop but then the system hung. Booted 6.18, installed original and then it could boot original kernel again.
Priority: Normal => HighSee Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=34560Severity: normal => criticalTarget Milestone: --- => Mageia 10Assignee: bugsquad => zen25000
> as original kernel must never be uninstalled. I am not sure what original exactly means in this scenario : - boot with Kernel 1 - upgrade to Kernel 2 - upgrade to Kernel 3 - upgrade to Kernel ... Kernel 1 must be kept until a new kernel as been proven working A simple way to maje sure keeping it is neither to remove the running kernel Regards
CC: (none) => boulshet
This is about Mageia Live with persistence. https://wiki.mageia.org/en/Persistent_live_systems As I said, § in Live the first kernel must *never* be removed. (tried it, it still booted it, all way to desktop but then hung) § The Live boot menu can only choose between the original and the last installed one, all other are a real waste and should be removed.
Thinking on another aspect: Is rok on Live scheduled to run automatically? Removing kernels may be very slow working on a USB stick, and that almost locks the system for a while, so should not run automatically in the background, i think...
Easiest and quickest fix is to omit it on Live. But somehow a system installed from live should work similar to a system installed from classic installer, so with Live installed and operating that way.
I am working on an update to rok which will address all these issues. In LIVE systems: It will protect the original kernel and display why it is retained. I think it should automatically fix the number of kernels to keep to 2 based on comment #3? Please advise. Assuming that a USB LIVE that is then installed to hard drive does not include 'mgalive' in the kernel command line when booted from the hard drive, then rok will revert to normal operation as in any other system. Could someone give me the output of cat /proc/cmdline from a system that has been installed to hard drive from a LIVE please? Do you think that the auto mode should be disabled if the system is LIVE? In reply to #1 rok will never remove a running kernel package, however urpme can.
Thinking about the auto mode, I would prefer that the config default remains at ON but when run in a LIVE the default is overridden to OFF. This would then automatically revert to the normal default ON state when moved to hard drive.
I asked on QA list if someone can supply that /proc/cmdline > I think it should automatically fix the number of kernels to keep to 2 based on comment #3? Please advise. The latest kernel user installs may be of same series that original kernel, or not. So rok will count them in two different categories or not. > Do you think that the auto mode should be disabled if the system is LIVE? That is my opinion currently, but may change. Saving space in Live is good, but apart from system going extremely sluggish for some users because USB stick is slow is not good, and also see Bug 34964 - xfce - when a kernel is removed, file manager windows pops up fullscreen for all partitions (In reply to Barry Jackson from comment #7) > Thinking about the auto mode, I would prefer that the config default remains > at ON but when run in a LIVE the default is overridden to OFF. And this is stored in a config file? > This would then automatically revert to the normal default ON state when moved to hard drive. Would it really revert? When Live installs also all configurations are copied.
You can test whether you are running in a live system or in an installed system with test -e /run/mgalive
CC: (none) => mageia
> The latest kernel user installs may be of same series that original kernel, or not. So rok will count them in two different categories or not. Hmm.. I will ponder that. > Would it really revert? When Live installs also all configurations are copied. Yes it would - this is not stored but fixed at 2 when run in LIVE and taken from config when not. @Martin - thanks, it seems fine using grep -q 'mgalive' /proc/cmdline, is there any preference? I could .OR. both methods if you can think of any way one would give a false negative or be more prone to error? If anyone wants to test my current github main then please try to break it :) git clone https://github.com/barjac/remove-old-kernels.git cd remove-old kernels run with ./remove-old-kernels in the same folder (NOT rok)
I have been pondering: > The latest kernel user installs may be of same series that original kernel, or not. So rok will count them in two different categories or not. Yes it would but I don't think this is an issue for rok to try to solve! Surely the package management system or kernel scripts or user should not allow this situation to arise in the first place. Even if rok counted all kernel packages in total then it would not know which to remove. The user can use urpme. I am not prepared to attempt to address this in rok as it would add excessive complication to the code and possibly cause other corner case breakage. Besides I don't have time ;) rok will still do the job of avoiding a build up of old kernels (of the same flavour) in a LIVE when run manually from time to time. If a majority want auto to work in LIVE then I will restore it (its currently disabled), so users can disable it at will.
@Barry, either method should be reliable. The user could create false positives, but I don't think they could create false negatives. I use the existence of /run/mgalive in other places,
I agree with Comment 11: let rok work as it normally do, with number to keep fixed (or default) at 2 in Live mode. In the case user only installs kernels of another series than original, there will be only one extra (not selectable to boot). If he install one or more of oiriginal series, then several of another series there will be two extras. If user installs two other series, etc, like rok work normally, total number of kernels increase. It is not too much to ask the user to remove extra kernels manually, which always have been the case before rok existed anyway, and mg10 is the first Live to carry it. When we are finished here i will add a note how it works at https://wiki.mageia.org/en/Persistent_live_systems I think you should put updated packages in mga9 & 10 testing repos to try out. ---- Possible enhancements to ponder in the future: § Also keep total number of kernels limited (say to 5) this would benefit both live and normal installs for example when /boot is limited, like i have on most of my systems and i test various kernel series... but i admit this is not normal user usage. § Trig run of rok every time a kernel have been installed, instead of schedule. That way user is not surprised as much for some random slowness or the mentionned xfce behaviour Bug 34964. How to implement that is not my cup of tea...
(In reply to Morgan Leijström from comment #13) > I agree with Comment 11: let rok work as it normally do, with number to keep > fixed (or default) at 2 in Live mode. > In the case user only installs kernels of another series than original, > there will be only one extra (not selectable to boot). > > If he install one or more of oiriginal series, then several of another > series there will be two extras. > > If user installs two other series, etc, like rok work normally, total number > of kernels increase. > > It is not too much to ask the user to remove extra kernels manually, which > always have been the case before rok existed anyway, and mg10 is the first > Live to carry it. > All above agreed > When we are finished here i will add a note how it works at > https://wiki.mageia.org/en/Persistent_live_systems OK thanks I will take a look when its done. > > I think you should put updated packages in mga9 & 10 testing repos to try > out. I would rather not push anything to Mga repos as there are translation updates needed yet. Please just pull from github to test as I outlined in #10 (Mga9 or 10 makes no difference). It is then simple to update with a 'git pull' and re-test when/if a change is needed, rather than updating a package. > > ---- > > Possible enhancements to ponder in the future: > > § Also keep total number of kernels limited (say to 5) this would benefit > both live and normal installs for example when /boot is limited, like i have > on most of my systems and i test various kernel series... but i admit this > is not normal user usage. No, the 'packages to keep' is a user choice and should not be limited. > > § Trig run of rok every time a kernel have been installed, instead of > schedule. That way user is not surprised as much for some random slowness > or the mentionned xfce behaviour Bug 34964. I don't understand why rok would be causing automounting of disks etc. > How to implement that is not my > cup of tea... This would not be for rok to control. Any user can disable auto with one simple command as root: rok -A0 For this reason I have decided not to force auto off in LIVE. Maybe something to mention in the wiki? Regarding running rok after a kernel update... This not straightforward as until the grub menu has been updated and the system has rebooted into the new kernel, or another depending on the grub settings, then the choices made by rok could be quite different. Again this is a user choice. Maybe turn off rok auto and add rok to autostart to run on each boot. Some users don't reboot for months so there is no one size fits all :)
(In reply to Barry Jackson from comment #14) > (In reply to Morgan Leijström from comment #13) > I would rather not push anything to Mga repos as there are translation > updates needed yet. > Please just pull from github to test as I outlined in #10 (Mga9 or 10 makes > no difference). OK. Never used git. (blush) Should learn, but now weekend is over, need to $work full schedule. > > > > Possible enhancements to ponder in the future: > > > > § Also keep total number of kernels limited ... > No, the 'packages to keep' is a user choice and should not be limited. What i meant: when the *count of kernels of all categories combined* is too high, uninstall the oldest (in Live mode the next oldest) And yes that setting should also be user configurable. Default rather high (maybe 5? 6?) but to 2 on Live, and it will keep original & newest only :) > I don't understand why rok would be causing automounting of disks etc. Not directly. Actually i did not test to trig the behaviour using rok, but when i uninstall a kernel in Live Xfce, i see this behaviour. I assume it does not matter if it is me or rok that run the command to uninstall. > Any user can disable auto with one > simple command as root: rok -A0 > Maybe something to mention in the wiki? Good idea. > there is no one size fits all :) That is true.
> What i meant: when the *count of kernels of all categories combined* is too > high, uninstall the oldest (in Live mode the next oldest) rok does not keep track of the total count and this is where I don't want to go. > And yes that setting should also be user configurable. The only users dealing with lots of different flavours of kernel are testers, developers or power users and they are capable of keeping track of their own systems. > Default rather high (maybe 5? 6?) but to 2 on Live, and it will keep original > & newest only :) The default is 3 of each flavour which suits the original purpose of rok which was to stop user's systems breaking when they ran out of disk space with 50+ kernels installed. Considering that: It has been doing that successfully for several years now. It has some advanced features that are useful to QA. It will soon cope with LIVE installations and not break when these are transferred to hard disk. Update from Mg9->10 is handled cleanly. It is flexible enough to be used by other system routines like rpm scriptlets if necessary. ... I think it should be adequate for now. I have updated all the i18n translations to suit the LIVE changes and will push a new package update soon to testing, unless I get any adverse testing reports in github.
remove-old-kernels-1.0.2 is now in Cauldron please test. Some small additional translations have been done using AI, so maybe users with non-English systems could look out for any mistakes? If it is considered necessary I can push an update to Mga9, however I really don't think its needed. Please test.
Created attachment 15307 [details] Mga9 LIVE before removal
Created attachment 15308 [details] Same after removal
Per Comment19 it keep 2 + original in Live, three of same sort (kernel-devel) Didn't we mean it should be two in total in this case?
(In reply to Morgan Leijström from comment #20) > Per Comment19 it keep 2 + original in Live, three of same sort (kernel-devel) > > Didn't we mean it should be two in total in this case? Probably yes, by protecting the oldest which is then not counted, we need to fix the 'number to keep' at one now, not two. I will test and update it.
However, if you have as in comment 19 two plus original, you could decide to manually uninstall the latest making the other the latest. If the other had been removed by rok that would not be possible. Is that acceptable?
(In reply to Barry Jackson from comment #22) > However, if you have as in comment 19 two plus original, you could decide to > manually uninstall the latest making the other the latest. If you choose to uninstall the latest, the Live boot menu will not chow an alternative to boot anything else than original kernel. On live there is never anything positive with deleting last kernel, and any kernel between original and last installed can never be selected for boot even if last installed is removed; the choice to boot it is also removed. So it all boils down to that rok on Live should optimally remove anything but original and last installed.
(In reply to Morgan Leijström from comment #23) OK, I will continue as in #21 then.
So if a new updated kernel is broken then booting from the original and manually re-installing a previous recent version is the way to recover to a working system. rok will remove the broken one as it was installed before the working recent one. That makes sense and should be (maybe is?) in the wiki.
(In reply to Barry Jackson from comment #25) > So if a new updated kernel is broken then booting from the original and > manually re-installing a previous recent version is the way to recover to a > working system. Exactly > rok will remove the broken one as it was installed before > the working recent one. Yes - it must operate on install date - keep last installed one regardless of its version number is higher or lower. > That makes sense and should be (maybe is?) in the wiki. Yep. Um do we have a wiki on rok itself only? Best to make such, for other pages to link to.
Created attachment 15310 [details] v1.0.3 in LIVE before removal Before
Created attachment 15311 [details] v1.0.3 in LIVE after removal After
That is correct behaviour :) Next test: In this last state, 1) install 6.6.116 2) install 6.6.105 3) run rok: it should uninstall 6.6.116 (keep latest installed, not highest version)
And so, in Live mode, when rok knows which is original and which is latest installed, maybe it is not too complicated to make it simply uninstall all other kernels of all nametypes? (except one that is in use - happens between kernel install and reboot) If you like, try backport https://wiki.mageia.org/en/Kernel_flavours#Backport_kernels
In case it's not clear, the "latest" option in the Live boot menu relies solely on the soft links /boot/vmlinuz and /boot/initrd.img. It doesn't care what kernel version they link to, so if you need to restore booting from another kernel, you can do so by manually changing those links.
(In reply to Martin Whitaker from comment #31) > In case it's not clear, the "latest" option in the Live boot menu relies > solely on the soft links /boot/vmlinuz and /boot/initrd.img. It doesn't care > what kernel version they link to, so if you need to restore booting from > another kernel, you can do so by manually changing those links. In which case maybe restricting 'kernels to keep' in rok to one for LIVE is a bad idea? If others can be used why does LIVE restrict selection to only two? Could the link switching not be provided, or conventional grub-mkconfig be used?
(In reply to Barry Jackson from comment #32) > If others can be used why does LIVE restrict selection to only two? Could > the link switching not be provided, or conventional grub-mkconfig be used? The persistent partition is mounted as an overlay to the base filesystem (using overlayfs). That only happens when the Linux kernel is booted. When GRUB starts, it reads grub.cfg from the base filesystem. Possibly we could persuade GRUB to look in the overlay and load a different configuration, but that's more complexity. IMO, anyone doing many updates to a persistent live system would be better off doing a standard installation onto the USB drive.
Thanks for the explanation Martin, I agree. I will close this now as the major concern about removing the original kernel is now fixed.
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
Thank you for the work Barry, and Martin for your valuable input. Please check if I integrated the wisdom correctly: https://wiki.mageia.org/en/Persistent_live_systems#Kernel_maintenance https://wiki.mageia.org/en/Persistent_live_systems#Original_kernel
Hi Morgan, The passage beginning "We have a helper" worries me. Is that true? I was not aware that rok had been included in Mageia 9 LIVE systems. The version in Mga9 will not protect the original kernel as I was not aware of that requirement back then. I would suggest not using or including rok in Mga9 LIVE isos if they are ever re-created. The alternative would be to update the package in Mga9 in case any users update and run rok, at least then it would do no damage.
Hi Barry OOPS I forgot we did only push this on mga10! Need to be updated on mga9 as well. Because, Yes remove-old-kernels is included on Live mga9 and mga10. And on both, rok displays it is in automatic mode. (And I see /etc/cron.weekly/remove-old-kernels.cron exists) When we have updated rok in mga9 there is no problem: If user make persistence partition and do a full update, she will get both new kernel and and new rok :) We will not officially spin new mga9Live (I personally think we *should* have easily made updated mga9Live2, 3, etc with no change but updated packages...) But advanced users can spin their own updated/customised lives using https://wiki.mageia.org/en/Draklive2 ___Comments A) I confirm it works perfectly on mga10 now, keeping original, running, and last kernel. Uninstalling the rest - leaving only original and last if you run one of them. B) The man page need updating for Live mode. C) rok runs weekly. I see we have cronie-anacron installed. IIUC that means that for example if system have been unused for say 8 days - rok (and the other two tasks in /etc/cron/weekly in sequence) then runs this after booted, after the delay specified in /etc/anacrontab, which i see is 25 minutes (mga9 Live). - Did I understand all that correctly?
Target Milestone: Mageia 10 => ---Status: RESOLVED => REOPENEDVersion: Cauldron => 9Resolution: FIXED => (none)
(In reply to Morgan Leijström from comment #37) > Hi Barry > > OOPS I forgot we did only push this on mga10! > Need to be updated on mga9 as well. OK I agree but will finish updating as elow in cauldron first. > > Because, > Yes remove-old-kernels is included on Live mga9 and mga10. > And on both, rok displays it is in automatic mode. > (And I see /etc/cron.weekly/remove-old-kernels.cron exists) Exactly. > > When we have updated rok in mga9 there is no problem: > If user make persistence partition and do a full update, she will get both > new kernel and and new rok :) Yes > ----snip > ___Comments > > A) I confirm it works perfectly on mga10 now, keeping original, running, and > last kernel. Uninstalling the rest - leaving only original and last if you > run one of them. Yes and will only leave one of other flavours which won't normally boot anyway. > > B) The man page need updating for Live mode. Yes I will do that. More AI translations :( > > C) rok runs weekly. I see we have cronie-anacron installed. IIUC that means > that for example if system have been unused for say 8 days - rok (and the > other two tasks in /etc/cron/weekly in sequence) then runs this after > booted, after the delay specified in /etc/anacrontab, which i see is 25 > minutes (mga9 Live). - Did I understand all that correctly? I think so - it rings a bell but it's a few years ago since I studied those man pages!
Tested just now my LIVE Mga9 with two kernels, original and latest and it will only boot into the original. 6.4.9 kernel. Any ideas? The grub menu shows "F1 latest..." so I hit F1 and then ENTER - That seems logical unless I misunderstand the menu. [live@localhost ~]$ ll /boot total 167988 -rw-r--r-- 1 root root 268680 Aug 19 2023 config-6.4.9-desktop-4.mga9 -rw-r--r-- 1 root root 273029 Nov 3 15:49 config-6.6.116-desktop-1.mga9 drwxr-xr-x 1 root root 4096 Jan 30 2024 dracut/ drwx------ 3 root root 26 Aug 20 2023 EFI/ -rw-r--r-- 1 root root 65662020 Nov 7 2024 initrd-6.4.9-desktop-4.mga9.img -rw------- 1 root root 69357276 Dec 16 00:21 initrd-6.6.116-desktop-1.mga9.img lrwxrwxrwx 1 root root 33 Dec 16 00:21 initrd-desktop.img -> initrd-6.6.116-desktop-1.mga9.img lrwxrwxrwx 1 root root 33 Dec 16 00:21 initrd.img -> initrd-6.6.116-desktop-1.mga9.img -rw-r--r-- 1 root root 159232 Aug 19 2023 symvers-6.4.9-desktop-4.mga9.xz -rw-r--r-- 1 root root 166968 Nov 3 15:49 symvers-6.6.116-desktop-1.mga9.xz -rw-r--r-- 1 root root 6701854 Aug 19 2023 System.map-6.4.9-desktop-4.mga9 -rw-r--r-- 1 root root 7321953 Nov 3 15:49 System.map-6.6.116-desktop-1.mga9 lrwxrwxrwx 1 root root 30 Dec 16 00:21 vmlinuz -> vmlinuz-6.6.116-desktop-1.mga9 -rw-r--r-- 1 root root 10519296 Aug 19 2023 vmlinuz-6.4.9-desktop-4.mga9 -rw-r--r-- 1 root root 11575808 Nov 3 15:49 vmlinuz-6.6.116-desktop-1.mga9 lrwxrwxrwx 1 root root 30 Dec 16 00:21 vmlinuz-desktop -> vmlinuz-6.6.116-desktop-1.mga9
(In reply to Barry Jackson from comment #39) > The grub menu shows "F1 latest..." > so I hit F1 Which make it toggle to original > and then ENTER So you boot that now chosen original kernel... I misunderstood it too first time :-) At least it default to latest every boot. --- On the subject of clarity... This is current state: System: Mageia release 10 (Cauldron) for x86_64 | Kernels in /boot/:5 | AUTO:1 | KEEP:1 ==> kernel-desktop 1 : Keep : : kernel-desktop-6.18.4-1.mga10-1-1.mga10.x86_64 Wed 21 Jan 2026 23:00:14 CET 2 : Remove: : kernel-desktop-6.18.4-2.mga10-1-1.mga10.x86_64 Wed 21 Jan 2026 22:58:17 CET 3 : Remove: : kernel-desktop-6.18.6-1.mga10-1-1.mga10.x86_64 Wed 21 Jan 2026 22:49:51 CET 4 : Keep : U : kernel-desktop-6.18.4-3.mga10-1-1.mga10.x86_64 Wed 21 Jan 2026 22:28:17 CET 5 : Keep : L : kernel-desktop-6.12.62-5.mga10-1-1.mga10.x86_64 Sat 20 Dec 2025 15:07:10 CET U = In use now L = LIVE system original kernel Like the indicator letters U & L here, it would be nice if it also indicated latest installed which is the reason number one here on Live is kept. For future revisions - not important but nice.
(In reply to Morgan Leijström from comment #40) > (In reply to Barry Jackson from comment #39) > > The grub menu shows "F1 latest..." > > so I hit F1 > > Which make it toggle to original > > > and then ENTER > > So you boot that now chosen original kernel... > > > I misunderstood it too first time :-) Like the F2 Language choice, what's displayed in the square brackets is the current selection. Whichever way round I did it, it would be open to misinterpretation.
This problem is found on other systems, devices, machines too... Some display what it currently is, some what the button will make it. You get confused when using different solutions. To express more clearly there need to be more text, or radio buttons, or a knob to turn (real life) Possibly this is a solution, if not to long: [F1] toggles kernel. Now selected: last installed.
There was recently a similar situation in FreeDV where there is a button which toggles between 'Analog' and 'Digital' modes. The button label when in Digital mode said 'Analog' and vice-versa. This caused endless confusion. The solution adopted was to precede the labels with 'Switch to ', problem solved. Maybe that boot menu should do the same?
remove-old-kernels-1.0.4-1.mga10 is now in cauldron. I will push it to Mga9 updates_testing shortly.
remove-old-kernels-1.0.5 has been freeze requested to be submitted to cauldron. remove-old-kernels-1.0.5 has been submitted to Mageia 9 updates_testing. Update Advisory ########################## This updated version of remove-old-kernels correctly handles kernel removal in persistent LIVE systems and protects the originally installed kernel from being removed. There are other bug fixes and translation improvements since the last version. Packages Affected ########################## remove-old-kernels-1.0.5-1.mga9.noarch References ########################## https://bugs.mageia.org/show_bug.cgi?id=34951
Assignee: zen25000 => qa-bugs
Updated https://wiki.mageia.org/en/Persistent_live_systems#Kernel_maintenance
Keywords: (none) => advisory
Morgan as reporter you can provide a test about this bug? Thank you
Flags: (none) => test_passed_mga9_64+, test_passed_mga9_32+
I see that rok --help contain info on the new status Letter for Live original kernel. For next iteration add in help that when running in Live number of kernel of each flavour is hard set to 2, and add information on Live mode in man rok. I dont want to hold this release for that.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2026-0008.html
Resolution: (none) => FIXEDStatus: REOPENED => RESOLVED
(In reply to Morgan Leijström from comment #48) > I see that rok --help contain info on the new status Letter for Live > original kernel. It also adds "LIVE System" (for 10 languages) to the start of the header bar. > For next iteration add in help that when running in Live number of kernel of > each flavour is hard set to 2, and add information on Live mode in man rok. If anyone tries to change the 'number to keep' using -n or -N to other than 1 in a LIVE, they will get an error message "In a LIVE system N is fixed." From man rok: " In a LIVE system with persistence only one kernel plus the original is kept, since only those two are bootable. It will never remove the running kernel, or the original kernel in a LIVE system with persistence. " > > I dont want to hold this release for that. I think what we have is adequate, especially since any changed strings in the help need translation.
CC: (none) => zen25000
Good, sorry I missed when reading too fast!
My 2 cents on the matter (not having read all of the above comments), as a simple user. Maybe it is too much, but when I used to do manually what "remove-old-kernels" does now automatically, I always kept the very first kernel. I am talking about the one which I did the installation of Mageia with, the one which could be three years old. ...as a precaution. Because I knew, that this one worked for sure.
CC: (none) => nikos5446.amigo969