mgorny
commented
1 year ago Hmm, I suspect kernel-install may be actually doing this. As you can see in the output, EK doesn't intend to remove moduledir.
Open anyuta1166 opened 2 years ago
mgorny
commented
1 year ago Hmm, I suspect kernel-install may be actually doing this. As you can see in the output, EK doesn't intend to remove moduledir.
Nowa-Ammerlaan
commented
1 month ago Probably we should not call kernel-install when the kernel is a genkernel-kernel. These kernels were never installed with /sbin/installkernel to begin with, so removing them via that mechanism is bound to get weird. The problem is detecting if a kernel is a genkernel-kernel.
Anyway, if this is indeed the problem. Then the workaround is to use the --no-kernel-install argument.
BratishkaErik
commented
1 month ago Just to help a little bit, I saw this issue happen with my "gentoo-kernel" dist-kernel too, but noticed it only after I changed whole layout from "plain kernel without initramfs" to "signed UKI with initramfs and plymouth and else inside", so unfortunately IDK which particular change caused this.
Nowa-Ammerlaan
commented
1 month ago Just to help a little bit, I saw this issue happen with my "gentoo-kernel" dist-kernel too, but noticed it only after I changed whole layout from "plain kernel without initramfs" to "signed UKI with initramfs and plymouth and else inside", so unfortunately IDK which particular change caused this.
That happens because when switching kernel layouts like that the detection of whether a module directory is still needed by another kernel does not take into account the kernels installed in the old layout.
BratishkaErik
commented
1 month ago Just to help a little bit, I saw this issue happen with my "gentoo-kernel" dist-kernel too, but noticed it only after I changed whole layout from "plain kernel without initramfs" to "signed UKI with initramfs and plymouth and else inside", so unfortunately IDK which particular change caused this.
That happens because when switching kernel layouts like that the detection of whether a module directory is still needed by another kernel does not take into account the kernels installed in the old layout.
In my case old layout is long gone, but I can still reproduce this error even at this moment:
$ doas eclean-kernel -n1
Legend:
[-] file being removed
[x] file does not exist (anymore)
[+] file being kept (used by other kernels)
* Removing kernel other 6.10.11-gentoo-old (not referenced by bootloader (symlinks))
[-] /boot/vmlinuz-6.10.11-gentoo-old.efi
[+] /lib/modules/6.10.11-gentoo/../../../src/linux-6.10.11-gentoo
[+] /lib/modules/6.10.11-gentoo
[-] /boot/vmlinuz-6.10.11-gentoo-old.png
Removed 1 kernels
$ doas exa /lib/modules/6.10.11-gentoo
build kernel modules.builtin.modinfo modules.order System.map vmlinuz
config modules.builtin modules.builtin.objs source video
$ doas depmod
$ doas exa /lib/modules/6.10.11-gentoo
build modules.alias.bin modules.builtin.modinfo modules.devname modules.symbols.bin video
config modules.builtin modules.builtin.objs modules.order modules.weakdep vmlinuz
kernel modules.builtin.alias.bin modules.dep modules.softdep source
modules.alias modules.builtin.bin modules.dep.bin modules.symbols System.map
Hello. I've found rather critical bug that caused my server malfunction for several hours (time needed to recompile a kernel).
Steps to reproduce:
1) Compile a kernel with genkernel. 2) Recompile the same kernel version with genkernel again (for example, I decided to recompile the kernel with different config). 3) Run eclean-kernel -n 1
After the second compilation you have the following layout:
Now run eclean-kernel:
And you end up with this:
For some reason, eclean-kernel removed most of the /lib/modules/5.17.9-gentoo-x86_64/modules.* files, leaving only modules.builtin, modules.builtin.modinfo and modules.order.
This makes the system unable to load any modules. I've accidentally found this after a reboot - hardware attached to my server wasn't working because the modules were not loaded.