Hi guys. Since upgrading to Leap 15.4, I’ve noticed that anytime I install updates that result in the regeneration of the /boot/initrd-* files, it seems that dracut generates new initrd images for kernels that are no longer installed on this machine.
This machine, for example, has /etc/zypp/zypp.conf configured to keep no more than 6 kernels: latest,latest-1,latest-2,running,oldest plus a specific kernel version that’s known to work. And, not surprisingly, ‘rpm -qa’ confirms that only 5 kernels are installed:
xxxx:/# rpm -qa | grep kernel-default-5
kernel-default-5.12.10-lp152.5.1.g332b26c.x86_64
kernel-default-5.18.10-lp153.2.1.g97c4fd2.x86_64
kernel-default-5.18.6-lp153.2.1.g5aa0763.x86_64
kernel-default-5.18.9-lp153.3.1.ge00841d.x86_64
kernel-default-5.18.12-lp153.2.1.g3198c22.x86_64
(plus, of course, all the related packages for each kernel... -syms, -source, -devel, etc)
xxxx:/#
However, today dracut generated 37 initrd files, most of which were for kernels that were long since purged:
xxxx:/boot# ls -l initrd-5.13*
-rw------- 1 root root 14300715 Jul 21 09:24 initrd-5.13.0-lp153.2.g6ed423b-default
-rw------- 1 root root 14300715 Jul 21 09:24 initrd-5.13.0-lp153.5.gaa40472-default
-rw------- 1 root root 14300715 Jul 21 09:24 initrd-5.13.0-lp153.6.g9140415-default
.... snip ....
-rw------- 1 root root 14300715 Jul 21 09:25 initrd-5.13.9-lp153.2.g19b1d90-default
-rw------- 1 root root 14300715 Jul 21 09:25 initrd-5.13.9-lp153.3.g2e9639b-default
xxxx:/boot#
xxxx:/boot# rpm -qa | grep 5.13.9
xxxx:/boot#
So while there are no 5.13.9-related packages installed anymore, dracut still thinks that it needs to generate a corresponding initrd. So what’s not being cleaned-up when zypper auto-purges old kernels? A naive grep of /etc, /boot and /var didn’t show anything promising…
Any clues?
Show full output of “ls -l /lib/modules”.
Thanks for the suggestion. Interesting. Okay. So there are presently 95 module trees in /lib/modules
xxxx:/lib/modules> ls -l | wc -l
95
xxxx:/lib/modules>
(I’m won’t paste the actual listing unless someone actually asks for it).
I guess these directories aren’t getting deleted when the corresponding kernel RPMs are removed because of the out-of-kernel ‘zenpower’ and/or ‘it87’ drivers that are getting built/installed via dkms.
So there are 95 module trees but only 37 initrd files. At a glance the difference between the trees that generate initrd files and those that don’t is: those that generate initrd files have modules.* files so perhaps that’s what dracut is looking for when it determines what initrd files to generate:
xxxx:/lib/modules> ls 5.14.2-lp153.3.g314dce0-default/
kernel modules.builtin.alias.bin modules.dep.bin modules.symbols
modules.alias modules.builtin.bin modules.devname modules.symbols.bin
modules.alias.bin modules.dep modules.softdep
xxxx:/lib/modules>
whereas
xxxx:/lib/modules> ls 5.17.2-lp153.2.gb49cf22-default/
kernel
xxxx:/lib/modules>
It’s not immediately obvious why those modules.* files are getting purged from some trees but not others.
Maybe you have build something “by Hand”?
Maybe because you do not show it…
> Maybe you have build something “by Hand”
Sure. I said that. dkms is building/installing a pair of out-of-tree drivers. So I completely understand why zypper isn’t able to remove /lib/modules/xxxxxx since those directories aren’t empty after zypper has removed all files associated with a particular kernel RPM.
But .ko files built and installed by dkms ought to be present in all of the /lib/modules/xxxxx trees (well, the ‘zenpower’ module is only present in recent trees but the ‘it87’ module would be in all of them). So the presence of those dkms-installed modules doesn’t seem to have an effect on whether files like /lib/modules/xxxxx/modules.dep are deleted when kernels are removed and whether dracut assembles a corresponding initrd file.
xxxx:/lib/modules> ls -R 5.17.2-lp153.2.gb49cf22-default
5.17.2-lp153.2.gb49cf22-default:
kernel
5.17.2-lp153.2.gb49cf22-default/kernel:
drivers
5.17.2-lp153.2.gb49cf22-default/kernel/drivers:
hwmon
5.17.2-lp153.2.gb49cf22-default/kernel/drivers/hwmon:
it87 zenpower
5.17.2-lp153.2.gb49cf22-default/kernel/drivers/hwmon/it87:
it87.ko
5.17.2-lp153.2.gb49cf22-default/kernel/drivers/hwmon/zenpower:
zenpower.ko
xxxx:/lib/modules>
versus
xxxx:/lib/modules> ls -R 5.13.0-lp153.5.gaa40472-default/
5.13.0-lp153.5.gaa40472-default/:
kernel modules.alias.bin modules.builtin.bin modules.dep.bin modules.softdep modules.symbols.bin
modules.alias modules.builtin.alias.bin modules.dep modules.devname modules.symbols
5.13.0-lp153.5.gaa40472-default/kernel:
drivers
5.13.0-lp153.5.gaa40472-default/kernel/drivers:
hwmon
5.13.0-lp153.5.gaa40472-default/kernel/drivers/hwmon:
it87
5.13.0-lp153.5.gaa40472-default/kernel/drivers/hwmon/it87:
it87.ko
xxxx:/lib/modules>
An initrd was generated for 5.13.0-lp153.5 but not for 5.17.2-lp153.2.
Anyway, it seems like the solution will be to manually remove those unneeded module trees. I’ll just have to remember to do that periodically to keep from generating dozens of unnecessary initrd files.
My modules are not build into the kernel tree, I use the updates directory.
The updates directory is preferred before the kernel tree when modules have the same name…
Also no need of dkms because of the weak-update directory…
Also I use rpms to install them.
This modules will not be deinstalled by purge-kernel.service