I’ve gone through my system purging old kernels, etc. with rm I’m running 13.1, defacto grub2, but even though I have the file /boot/do_purge_kernels it doesn’t appear to be doing so. Is this something that only grub did? It seems like a regression to me to remove functionality, and to force the user to do it.
Failing that is there any way of telling grub2 to purge kernels? the config file says “do not edit” and I’ve not had a good look at /etc/grub.d but 20 minutes with Google shows that people are being told to purge manually, so before I spend any time on it, is it even possible?
That’s totally unrelated to grub. grub2 and grub only show the kernels that are added to their menu file.
When you install or remove kernels, the menu file should get adapted by the kernel package’s scripts.
Failing that is there any way of telling grub2 to purge kernels? the config file says “do not edit” and I’ve not had a good look at /etc/grub.d but 20 minutes with Google shows that people are being told to purge manually, so before I spend any time on it, is it even possible?
You can add/remove kernels manually, yes. Use e.g. YaST’s “Versions” tab to add/remove particular versions.
But there is a system service, that checks during boot whether /boot/do_purge_kernels exists, and purges the old kernels in that case.
Apparently this service is disabled on your system, enable it either in YaST->System->Services Manager, or with:
sudo systemctl enable purge-kernels
You can also run this service manually if you prefer:
sudo systemctl start purge-kernels
Or, as the service only calls a script, this will work as well, even if /boot/do_purge_kernels does not exist:
sudo purge-kernels.sh
Please note, that this service/scripts acts upon the settings regarding which kernels to keep in /etc/zypp/zypp.conf. If you haven’t ever changed them, it should keep 2 or 3 kernels, namely the running one, the latest (highest version), and the latest-1. (the first two normally should be that same, so if you don’t do anything special you’ll always have 2 kernel, the current one and the previous one)
So if it still doesn’t work, check those settings. (“multiversion.kernels” in /etc/zypp/zypp.conf)
If you just delete the directories then the system just does not know what happened you should remove them via yast or zypper. then the system will know what is going on.
rm the kernels will leave a mess with some parts of the system thinking they still exist and other not,.
Of course if you build you own kernels that is a different story since unless you tell it the system may not know that a new kennel is there. But if you are building kernels you should understand how things work anyway.
Yeah.
And to be absolutely clear: the purge-kernels script/service only handles kernels installed via RPM packages.
If you manually compile/install kernels, you have to clean up yourself. (maybe create a similar script/service that acts upon the actual files/directories in /boot/ and /lib/modules/ instead… )
I have here 13.1 and 13.2 but there is no purge-kernels.sh but i have found
/sbin/purge-kernels
which is a perl script and not a shell script. 13.1 the file belongs to mkinitrd and since mkinitrd is replaced by dracut in 13.2 that file is owned by dracut in 13.2
I used to build & patch the Nvidia module, only now I have a Radeon card at work
However, when I tried to run**/sbin/purge-kernels --test** It tried to delete the running kernel Though yes, I do have the following in /etc/zypp/zypp.conf:
multiversion = provides:multiversion(kernel)
&&
multiversion.kernels = latest,latest-1,running
and /etc/zypp/multiversion.d is empty
I tried to use it as a system service, but systemctl list-units shows the following:
purge-kernels.service loaded failed failed Purge old kernels
zypper list nothing but the kernel, though RPM lists loads of kernels. I’ll manually remove them from the RPM DB
Any idea why purge kernels tries to remove the running kernel?
Running kernel is 3.18.5-1.gf378da4. Though I also have, as of this morning, 3.19.0-1.g8a7d5f9 installed.
Well, that’s irrelevant for cleaning up the kernels anyway…
However, when I tried to run**/sbin/purge-kernels --test** It tried to delete the running kernel Though yes, I do have the following in /etc/zypp/zypp.conf:
Strange, it shouldn’t.
I tried to use it as a system service, but systemctl list-units shows the following:
purge-kernels.service loaded failed failed Purge old kernels
Apparently it cannot remove the kernels for some reason. What does “sudo systemctl status purge-kernels” say?
zypper list nothing but the kernel, though RPM lists loads of kernels. I’ll manually remove them from the RPM DB
What command did you run when “zypper list nothing but the kernel”?
What does “zypper se -si kernel” say?
zypper and RPM should show the same packages, as zypper just uses RPM to install/remove packages anyway.
If not, then something seems to be wrong either with your RPM database or zypper’s cache.
Try to clean zypper’s cache with “zypper clean -a” or by just deleting /var/cache/zypper/.
If they differ about what is installed, you’ll get problems anyway.
Any idea why purge kernels tries to remove the running kernel?
Running kernel is 3.18.5-1.gf378da4. Though I also have, as of this morning, 3.19.0-1.g8a7d5f9 installed.
Can you post the output please? And the output of “uname -a”.
I have the xen stuff as it’s a dependency of one of the others you get when you install the development option, I forget which.
I did have a lot more kernels listed but I wrote a script to cycle through rpm -e --nodeps to delete them all.
systemctl status purge-kernels
purge-kernels.service - Purge old kernels
Loaded: loaded (/usr/lib/systemd/system/purge-kernels.service; enabled)
Active: failed (Result: exit-code) since Fri 2015-02-13 13:54:41 CET; 2 days ago
Process: 5417 ExecStart=/sbin/purge-kernels (code=exited, status=1/FAILURE)
Process: 5414 ExecStartPre=/bin/rm -f /boot/do_purge_kernels (code=exited, status=0/SUCCESS)
Main PID: 5417 (code=exited, status=1/FAILURE)
CGroup: /system.slice/purge-kernels.service
Feb 13 13:54:41 xxxxx purge-kernels[5417]: error: Failed dependencies:
Feb 13 13:54:41 xxxxx systemd[1]: purge-kernels.service: main process exited, code=exited, s…LURE
Feb 13 13:54:41 xxxxx systemd[1]: Failed to start Purge old kernels.
Feb 13 13:54:41 xxxxx systemd[1]: Unit purge-kernels.service entered failed state.
Hint: Some lines were ellipsized, use -l to show in full.
It wants to remove kernel-desktop-3.18.5-1.1, but you probably run kernel-desktop-3.18.5-1.2.
So nothing wrong from purge-kernels side.
Why do you have kernel-default installed as well though? You could probably just remove that completely, also the later versions (you have to do that manually though).
I have the xen stuff as it’s a dependency of one of the others you get when you install the development option, I forget which.
The kernel-xen-devel packages are required by kernel-syms, which you should only need when wanting to build kernel modules (and not even then in most cases I think).
But that’s also no kernel…
I did have a lot more kernels listed but I wrote a script to cycle through rpm -e --nodeps to delete them all.
That’s exactly what purge-kernels does (without the --nodeps though I think), but it also removes the corresponding kmp , -source, -devel, and -syms packages.
systemctl status purge-kernels
purge-kernels.service - Purge old kernels
Loaded: loaded (/usr/lib/systemd/system/purge-kernels.service; enabled)
Active: failed (Result: exit-code) since Fri 2015-02-13 13:54:41 CET; 2 days ago
Process: 5417 ExecStart=/sbin/purge-kernels (code=exited, status=1/FAILURE)
Process: 5414 ExecStartPre=/bin/rm -f /boot/do_purge_kernels (code=exited, status=0/SUCCESS)
Main PID: 5417 (code=exited, status=1/FAILURE)
CGroup: /system.slice/purge-kernels.service
Feb 13 13:54:41 xxxxx purge-kernels[5417]: error: Failed dependencies:
Feb 13 13:54:41 xxxxx systemd[1]: purge-kernels.service: main process exited, code=exited, s…LURE
Feb 13 13:54:41 xxxxx systemd[1]: Failed to start Purge old kernels.
Feb 13 13:54:41 xxxxx systemd[1]: Unit purge-kernels.service entered failed state.
Hint: Some lines were ellipsized, use -l to show in full.
Try again with “sudo systemctl status -l purge-kernels”. The actual error message is truncated.
purge-kernels.service - Purge old kernels
Loaded: loaded (/usr/lib/systemd/system/purge-kernels.service; enabled)
Active: failed (Result: exit-code) since Fri 2015-02-13 13:54:41 CET; 3 days ago
Main PID: 5417 (code=exited, status=1/FAILURE)
Feb 13 13:54:41 xxxxx purge-kernels[5417]: error: Failed dependencies:
Feb 13 13:54:41 xxxx systemd[1]: purge-kernels.service: main process exited, code=exited, status=1/FAILURE
Feb 13 13:54:41 xxxxx systemd[1]: Failed to start Purge old kernels.
Feb 13 13:54:41 xxxxx systemd[1]: Unit purge-kernels.service entered failed state.
Though it’s looking good. The only reason I noticed is that zypper up was taking ages, and that was because mkinitrd was having to rebuild every kernel I had installed, not to mention the all the garbage that gets thrown to the screen by all the Radeon drivers.
No idea why it didn’t work during boot then, and we won’t be able to find out any more I suppose. OTOH, the was last run 3 (meanwhile 4) days ago, according to your output. So maybe the reason why it failed has been rectified/fixed meanwhile?
I guess you’ll just have to wait for the next kernel update to see whether it works then.
The only reason I noticed is that zypper up was taking ages, and that was because mkinitrd was having to rebuild every kernel I had installed, not to mention the all the garbage that gets thrown to the screen by all the Radeon drivers.
Yes, mkinitrd rebuilds the initrd for all installed kernels. It has to if you install new or updated kernel modules.
But I don’t understand what you mean with “all the garbage that gets thrown to the screen by all the Radeon drivers”.
Where do you get what garbage by which Radeon drivers?
So it appears to cleaned it’s act up a little. That must be what the kernel firmware update was. I have both drivers installed as I have both cards installed but only the Radeon is hooked up to a display.
Well, yes, mkinitrd prints which files/kernel modules it adds to the initrd.
But why would you be bothered about that?
Btw, this “radeon garbage” is the list of the firmware files for radeon chips, that are needed to operate them properly. And yes, they are contained in kernel-firmware.
I don’t think that kernel-firmware has been “cleaned up”. That firmware is necessary for radeon to work. I only have installed the one included in 13.2 here, so I cannot tell really (and I don’t know where you installed your kernels or kernel-firmware from anyway).
Maybe mkinitrd’s output has just been reduced?
But it also might be that mkinitrd has been optimized to add less unnecessary stuff to the initrd…
(although I don’t think mkinitrd is maintained at all any more, but then I also don’t know where you installed that from)
You could also switch to dracut, that shouldn’t print that “garbage” at all.
I wasn’t bothered so much as puzzled as to why it was producing so much output. Never had these problems on 11.3, but then that was before the PC refresh
I update daily, from the official repos, kernel from here: http://download.opensuse.org/repositories/Kernel:/HEAD/standard/ kernel-firware comes from the same place. mkinitrd comes from the 13.1-update repo. I thought I saw an update to mkinitrd recently, could have been something else behind it. Will check dracut.
On 11.3, having multiple Kernels installed was not supported/possible at all I think (at least not via RPMs).
mkinitrd comes from the 13.1-update repo. I thought I saw an update to mkinitrd recently, could have been something else behind it.
Hm. AFAICS the last update to mkinitrd for 13.1 was 7 months ago.
Will check dracut.
JFYI, openSUSE’s dracut is a drop-in replacement for mkinitrd. It contains a compatibility script “mkinitrd” that calls dracut with the correct parameters depending on the settings in /etc/sysconfig/. But I haven’t tried it myself on 13.1. (starting with 13.2, mkinitrd is not included any more and dracut is used instead)
)