Files in /boot are produced with: genkernel --dmraid --install --kernel-config=/root/kernel-config initramfs /boot/grub/grub.conf is for grub 1. Result: rh1 ~ # eclean-kernel -n8 ... * Removing kernel genkernel-x86_64-3.8.5-gentoo (vmlinuz does not exist) - /boot/initramfs-genkernel-x86_64-3.8.5-gentoo ... This is leaving the system unbootable until the genkernel is repeated. It removed all ramdisks in boot, but that of the running kernel is especially bad ;-) Reproducible: Always
Please paste the output of 'eclean-kernel --list-kernels' and 'eclean-kernel --pretend --debug' (both won't touch your files).
rh1 ~ # eclean-kernel --list-kernels 3.8.5-gentoo [3.8.5-gentoo]: - vmlinuz: /boot/vmlinuz-3.8.5-gentoo - systemmap: /boot/System.map-3.8.5-gentoo - config: /boot/config-3.8.5-gentoo - modules: /lib64/modules/3.8.5-gentoo - build: /usr/src/linux-3.8.5-gentoo genkernel-x86_64-3.8.5-gentoo [None]: - initramfs: /boot/initramfs-genkernel-x86_64-3.8.5-gentoo source [None]: - modules: /usr/src/linux-2.6.38-gentoo-r2 3.8.3-gentoo [3.8.3-gentoo]: - vmlinuz: /boot/vmlinuz-3.8.3-gentoo - systemmap: /boot/System.map-3.8.3-gentoo - config: /boot/config-3.8.3-gentoo - modules: /lib64/modules/3.8.3-gentoo - build: /usr/src/linux-3.8.3-gentoo ( The initramfs of the 3.8.3 kernel fell already victim to a previous eclean-kernel ;-) ) rh1 ~ # eclean-kernel --pretend --debug * Trying bootloader lilo * Trying bootloader grub2 * Trying bootloader grub ** /boot/grub/grub.conf found * In get_removal_list() These are the kernels which would be removed: - genkernel-x86_64-3.8.5-gentoo: vmlinuz does not exist - source: vmlinuz does not exist
@genkernel, could you help explaining me how genkernel exactly works and why? (In reply to comment #2) > rh1 ~ # eclean-kernel --list-kernels > 3.8.5-gentoo [3.8.5-gentoo]: > - vmlinuz: /boot/vmlinuz-3.8.5-gentoo > - systemmap: /boot/System.map-3.8.5-gentoo > - config: /boot/config-3.8.5-gentoo > - modules: /lib64/modules/3.8.5-gentoo > - build: /usr/src/linux-3.8.5-gentoo > genkernel-x86_64-3.8.5-gentoo [None]: > - initramfs: /boot/initramfs-genkernel-x86_64-3.8.5-gentoo Does genkernel always use this inconsistent naming between kernels and initramfs? I've got some genkernel bits in eclean-kernel already but they seem not to take this into consideration. > source [None]: > - modules: /usr/src/linux-2.6.38-gentoo-r2 This one confuses me a lot. Could you paste your 'ls -lh /lib/modules' as well? If there's anything you think could help me, please feel free to write it. I'm not using genkernel myself so it's more of a guessing game to me. I would be happy to improve the checks but I don't know how.
(In reply to comment #3) > @genkernel, could you help explaining me how genkernel exactly works and why? > > (In reply to comment #2) > > rh1 ~ # eclean-kernel --list-kernels > > 3.8.5-gentoo [3.8.5-gentoo]: > > - vmlinuz: /boot/vmlinuz-3.8.5-gentoo > > - systemmap: /boot/System.map-3.8.5-gentoo > > - config: /boot/config-3.8.5-gentoo > > - modules: /lib64/modules/3.8.5-gentoo > > - build: /usr/src/linux-3.8.5-gentoo > > genkernel-x86_64-3.8.5-gentoo [None]: > > - initramfs: /boot/initramfs-genkernel-x86_64-3.8.5-gentoo > > Does genkernel always use this inconsistent naming between kernels and > initramfs? I've got some genkernel bits in eclean-kernel already but they > seem not to take this into consideration. That naming seems to be genkernel's default; skimming over genkernel's man page I can't find an option to rename the ramdisk file, and my /etc/genkernel.conf is looking untouched. > > > source [None]: > > - modules: /usr/src/linux-2.6.38-gentoo-r2 > > This one confuses me a lot. Could you paste your 'ls -lh /lib/modules' as > well? Me too. There were remains of a 2.6.38 kernel, but only until a recent (over-)successful eclean-kernel. At the same moment of that source[none] I see: #ls -l /usr/src/linux-2.6.38* ls: cannot access /usr/src/linux-2.6.38*: No such file or directory But I think that might be some second not so relevant bug. > > If there's anything you think could help me, please feel free to write it. > I'm not using genkernel myself so it's more of a guessing game to me. I > would be happy to improve the checks but I don't know how. There are 2 config lines in grub.conf for each kernel, one for the image and one for the ramdisk: rh1 ~ # grep 3.8.5 /boot/grub/grub.conf kernel /boot/vmlinuz-3.8.5-gentoo root=/dev/ram0 init=/linuxrc ramdisk=8192\ real_root=/dev/mapper/pdc_dacchiefcip1 dodmraid initrd /boot/initramfs-genkernel-x86_64-3.8.5-gentoo To my eyes it looks like eclean-kernel is trying to handle the initrd lines also as kernels.
> > > source [None]: > > > - modules: /usr/src/linux-2.6.38-gentoo-r2 > > > > This one confuses me a lot. Could you paste your 'ls -lh /lib/modules' as > > well? > > Me too. There were remains of a 2.6.38 kernel, but only until a recent > (over-)successful eclean-kernel. At the same moment of that source[none] I > see: > #ls -l /usr/src/linux-2.6.38* > ls: cannot access /usr/src/linux-2.6.38*: No such file or directory > > But I think that might be some second not so relevant bug. Ah, got them. My fault, I had left over stale symlinks to /usr/src/linux-2.6.38-gentoo-r2 under /lib/modules from ancient hand cleanings. Removing those doesn't change eclean-kernel's issue with the ramdisk.
(In reply to comment #3) > @genkernel, could you help explaining me how genkernel exactly works and why? > > (In reply to comment #2) > > rh1 ~ # eclean-kernel --list-kernels > > 3.8.5-gentoo [3.8.5-gentoo]: > > - vmlinuz: /boot/vmlinuz-3.8.5-gentoo > > - systemmap: /boot/System.map-3.8.5-gentoo > > - config: /boot/config-3.8.5-gentoo > > - modules: /lib64/modules/3.8.5-gentoo > > - build: /usr/src/linux-3.8.5-gentoo > > genkernel-x86_64-3.8.5-gentoo [None]: > > - initramfs: /boot/initramfs-genkernel-x86_64-3.8.5-gentoo > > Does genkernel always use this inconsistent naming between kernels and > initramfs? I've got some genkernel bits in eclean-kernel already but they > seem not to take this into consideration. > The result above is strange, genkernel does inconsistency which breaks eclean-kernel, but that is mostly because genkernel only changes the names of the files it copies to /boot from the default names the rest of the install procedure does. With other words gentoo-sources-3.8.5 on x86_64 will with genkernel produce a result that is: uname -r = 3.8.5-gentoo /lib/modules/3.8.5-gentoo /boot/{initramfs,kernel,System.map}-genkernel-x86_64-3.8.5-gentoo I have had thoughts of looking into how to set this consistent but have not had the time.
(In reply to comment #6) > The result above is strange, genkernel does inconsistency which breaks > eclean-kernel, but that is mostly because genkernel only changes the names > of the files it copies to /boot from the default names the rest of the > install procedure does. > With other words gentoo-sources-3.8.5 on x86_64 will with genkernel produce > a result that is: > > uname -r = 3.8.5-gentoo > /lib/modules/3.8.5-gentoo > /boot/{initramfs,kernel,System.map}-genkernel-x86_64-3.8.5-gentoo > > I have had thoughts of looking into how to set this consistent but have not > had the time. I'm most worried about kernel installed with a different name than initramfs. i would suspect that the same naming on all three files would be beneficial but I'm not aware of all the reasons behind this particular naming. Could you tip me on how does genkernel generate the name? 'x86_64' is obtained somehow from the built kernel or based solely on $ARCH? I should probably just match '*-genkernel-*-X' to kernel 'X', in case someone wanted two different arch initramfses for the same kernel.
(In reply to comment #7) > Could you tip me on how does genkernel generate the name? 'x86_64' is > obtained somehow from the built kernel or based solely on $ARCH? Neither, as far as I can see. Genkernel is looking at $ARCH, but then feeding that into it's own logic to determine it. Then it is able to build the kernel for that arch (I'm not using that). > > I should probably just match '*-genkernel-*-X' to kernel 'X', in case > someone wanted two different arch initramfses for the same kernel. The latter shouldn't worry you. That doesn't sound like an use case a linux distribution should cope for, but rather an individual solution.
(In reply to comment #8) > (In reply to comment #7) > > Could you tip me on how does genkernel generate the name? 'x86_64' is > > obtained somehow from the built kernel or based solely on $ARCH? > > Neither, as far as I can see. Genkernel is looking at $ARCH, but then > feeding that into it's own logic to determine it. Then it is able to build > the kernel for that arch (I'm not using that). The whole thing is weird. Looking at the code, genkernel should actually append that ${KNAME}-${ARCH} (genkernel-x86_64) to your kernel name as well...
@lxnay, hope you don't mind being questioned. You seem to know genkernel best of the people who actually respond to bugs. Could you take a look at this and suggest some course of action?
Looks like the handbook may be a cause of a naming convention mismatch between kernel (vmlinuz-<ver>-gentoo) and a genkernel generated initramfs, specifically https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Kernel has a manually configured kernel followed by an optional section to use genkernel to build just and initramfs. This results in eclean-kernel thinking there's an incomplete set of genkernel related files and a complete set of manually configured kernel files.
eclean-kernel still seems to be doing this. # eclean-kernel -l genkernel-x86_64-4.20.12-gentoo [None]: - initramfs: /boot/initramfs-genkernel-x86_64-4.20.12-gentoo - last modified: 2019-03-11 14:59:56 4.20.12-gentoo [4.20.12-gentoo]: - vmlinuz: /boot/vmlinuz-4.20.12-gentoo - systemmap: /boot/System.map-4.20.12-gentoo - config: /boot/config-4.20.12-gentoo - modules: /lib64/modules/4.20.12-gentoo - build: /usr/src/linux-4.20.12-gentoo - last modified: 2019-03-11 14:59:02 4.20.12-gentoo.old [4.20.12-gentoo]: - vmlinuz: /boot/vmlinuz-4.20.12-gentoo.old - systemmap: /boot/System.map-4.20.12-gentoo.old - config: /boot/config-4.20.12-gentoo.old - modules: /lib64/modules/4.20.12-gentoo - build: /usr/src/linux-4.20.12-gentoo - last modified: 2019-03-11 14:47:02 # eclean-kernel --pretend --debug * Trying bootloader lilo * Trying bootloader grub2 ** /boot/grub/grub.cfg found * In get_removal_list() These are the kernels which would be removed: - genkernel-x86_64-4.20.12-gentoo: vmlinuz does not exist Seems like the simplest fix is to not let it remove any initramfs from the currently booting kernel versions.
For my installation, I started using genkernel, then moved to compiling my own kernel, but kept making the initramfs using genkernel --install initramfs. I don't think I needed to edit any grub config files because grub looks for any combination of kernel image and initramfs. If someone could point me to what needs editing in https://github.com/mgorny/eclean-kernel I could take shot at submitting a patch. Maybe just adding a flag for this particular behavior (don't delete a genkernel initramfs if an image of the same version exists). eclean-kernel -x initramfs does mostly work fine, and it's really the default behavior that might render a system unbootable.
Does this still happen after the recent naming changes in genkernel? If so, I suppose the easiest way to handle it would be to add 'initramfs-genkernel-' or alike to the prefixes list: https://github.com/mgorny/eclean-kernel/blob/master/ecleankernel/layout/std.py#L32
