Cloned disk, purge-kernels stopped working

Recently I transferred everything from one HD to another using clonezilla, including my OpenSuse 13.1. In order to make OpenSuse work after this I had to manually edit /etc/fstab and grub’s menu.lst.

After this, OpenSuse started working ok, except that now, for some reason, the purge-kernels service stopped working, and my grub list is getting flooded with new kernels. I don’t know what the problem is, or how to fix it.

You can manually remove them in Yast until the problem can be figured out

Well, what does “sudo systemctl status purge-kernels.service” say for a start?

Do you really have a lot of kernels installed, or is just grub.lst not updated?

As a side-note, I don’t think there have been many kernel updates for 13.1 recently that could “flood” your grub menu.
Are you using some additional kernel repo?

purge-kernels.service - Purge old kernels
Loaded: loaded (/usr/lib/systemd/system/purge-kernels.service; enabled)
Active: inactive (dead)
start condition failed at Sat 2016-07-16 19:39:51 EEST; 3min 30s ago
ConditionPathExists=/boot/do_purge_kernels was not met

Jul 16 19:39:51 linux-8111 systemd[1]: Started Purge old kernels.

Do you really have a lot of kernels installed, or is just grub.lst not updated?

Yast lists two versions for kernel-desktop as being installed. I don’t know if there is some other way of finding this out.

The purge service was able to update grub previously, but seemingly not anymore. I don’t know why.

Just run


# grub2-mkconfig -l /boot/grub2/grub.cfg

I haven’t checked very thoroughly, but it has been my impression that the purge service does not run “grub2-mkconfig”. Instead, it just edits “grub.cfg” to remove lines that refer to a kernel that it has purged.

That only applies to grub2 though, the OP mentioned grub.lst, i.e. it seems he’s using grub1.

@Warp:
Please post the output of:

grep TYPE /etc/sysconfig/bootloader

I haven’t checked very thoroughly, but it has been my impression that the purge service does not run “grub2-mkconfig”. Instead, it just edits “grub.cfg” to remove lines that refer to a kernel that it has purged.

No it doesn’t.

It only removes the installed kernel packages with rpm and doesn’t modify grub in any way. The rpm (un)install scripts of the kernel packages update the boot menu.

YaST shows all rpm packages installed on the openSUSE system, and that’s also exactly what purge-kernels acts upon. (IOW, if you manually compile and install kernels, you have to clean them up yourself)

Have a look in /boot whether there are other kernels (maybe from your other installations?)

The purge service was able to update grub previously, but seemingly not anymore. I don’t know why.

Just to be clear:
the service is only run whenever you really install a new kernel.
But as you have only 2 kernels installed, that seems not to be the problem.

I have a suspicion of what happened: Since I had to modify grub’s menu.lst file manually to make it work after cloning the disk, the service is not removing those modified entries. My guess is that, somehow, it’s seeing that they are modified and is not removing them. (Does it use some kind of hash, or whatever, to see which entries are its own, are which aren’t?)

I suppose that the next time the kernel updates, it will confirm or disprove my hypothesis.

Can you confirm you use legacy grub and not grub2??? grub.lst is a legacy grub file not a grub2 file. Legacy grub is no longer supported in Yast and thus may not auto-update like grub2 would. You must manually maintain it

As I wrote already, the purge-kernels service does not touch your grub config in any way.

If a kernel package is installed/uninstalled, the kernel package adds/removes its entry (via perl-bootloader).

So yes, it is to be expected that manually added entries persist.
Actually I would call it a bug if they were removed automatically… :wink:

That applies to grub1 at least. The grub2 menu gets generated automatically and manual changes that you made there directly get lost.
There are places where you can add custom entries too though (or you could even completely change the scripts that generate the menu), and these will also stay there unless you remove them again manually.

(Does it use some kind of hash, or whatever, to see which entries are its own, are which aren’t?)

IIRC, YaST does add comments with some hash if you create a menu entry in YaST.

But that’s probably irrelevant in your case.

It is no longer supported by YaST, but it is still supported by perl-bootloader (unless that changed recently, IIRC there were talks not too long ago about dropping pbl and really only support grub2), which manages the boot loader configuration.

And notice that this is about 13.1. I’m not sure, but I think grub1 may even still be supported by YaST there.

There are only two kernels (which the first two entries in menu.lst refer to). The other two entries in menu.lst refer to older kernels that are not there anymore.

I suppose it’s grub1. It did work before I moved Linux to another disk. I don’t understand why it would stop working just because of a disk change.

But anyway, we’ll see if the problem persists. It might be simply a question of it not removing menu entries that have been modified by hand.

a disk change can lead to different BY-UUID and other naming conventions it is possible if you are using older grub that it something did not get fully modified to take in to account possible ID changes