No vmlinuz found. This seems ridiculous. Perhaps `eclean-kernel` only looks in /boot?

[gabrielgg]

# eclean-kernel -p
eclean-kernel has met the following issue:

  SystemError('No vmlinuz found. This seems ridiculous, aborting.')

I believe this is due to the fact that my kernels, initramfs's and friends are in /, not /boot. Can anybody confirm?

[lekto]

Have similar problem, I'm using rEFInd and I have to put kernel/initramfs to /boot/EFI/Gentoo to get Gentoo logo in boot menu. It would be great if I could specify kernel/initramfs dir as eclean-kernel parameter.

[Tatsh]

I'm using systemd-boot so everything goes into /efi/EFI. However I already have something I wrote to delete old kernels from within there. I was just looking to use this utility to clean up old sources. I would expect to be able to use it this way with --no-bootloader-update but even with that I still get this error.

[matteganau]

I have this issue with using efibootmgr to boot EFI stub kernels in /boot/EFI/linux/example-kernel.efi.

[Nowa-Ammerlaan]

This issue should be fixed with the latest release and can probably be closed.

[luxifr]

I'm on 2.99.6 and still have this issue... this is how my /boot looks like:

/boot/
/boot/EFI
/boot/EFI/Lenovo
/boot/EFI/Lenovo/BIOS
/boot/EFI/Lenovo/BIOS/SelfHealing.fd
/boot/EFI/Linux
/boot/EFI/Linux/linux-6.1.53-gentoo-r1-x86_64-Default.efi
/boot/EFI/Linux/linux-6.1.53-gentoo-r1-x86_64-d31be9dfcc49461fbca1245249ac3ec9.efi
/boot/EFI/Linux/linux-6.1.53-gentoo-r1-luxbook-1-d31be9dfcc49461fbca1245249ac3ec9.efi
/boot/EFI/Linux/linux-6.1.53-gentoo-r1-luxbook-2-d31be9dfcc49461fbca1245249ac3ec9.efi
/boot/EFI/Linux/linux-6.1.57-gentoo-luxbook-2-d31be9dfcc49461fbca1245249ac3ec9.efi
/boot/System.map-6.1.53-gentoo-r1-x86_64
/boot/config-6.1.53-gentoo-r1-x86_64
/boot/vmlinuz-6.1.53-gentoo-r1-x86_64
/boot/loader
/boot/loader/random-seed
/boot/vmlinuz-6.1.53-gentoo-r1-luxbook-1
/boot/System.map-6.1.53-gentoo-r1-luxbook-1
/boot/config-6.1.53-gentoo-r1-luxbook-1
/boot/vmlinuz-6.1.53-gentoo-r1-luxbook-2
/boot/System.map-6.1.53-gentoo-r1-luxbook-2
/boot/config-6.1.53-gentoo-r1-luxbook-2
/boot/vmlinuz-6.1.53-gentoo-r1-luxbook-2.old
/boot/System.map-6.1.53-gentoo-r1-luxbook-2.old
/boot/config-6.1.53-gentoo-r1-luxbook-2.old
/boot/vmlinuz-6.1.57-gentoo-luxbook-2
/boot/System.map-6.1.57-gentoo-luxbook-2
/boot/config-6.1.57-gentoo-luxbook-2

per uname -r it's pretty clear which kernel is currently booted and how that maps to the files under /boot

luxbook / # uname -r
6.1.57-gentoo-luxbook-2

however...

luxbook / # eclean-kernel -p
eclean-kernel has met the following issue:

  SystemError('No vmlinuz found. This seems ridiculous, aborting.')

If you believe that the mentioned issue is a bug, please report it
to https://github.com/mgorny/eclean-kernel/issues. If possible,
please attach the output of 'eclean-kernel --list-kernels' and your
regular eclean-kernel call with additional '--debug' argument.

this seems do be down to the detection of which layout to assume though... if I force std, it works

luxbook / # eclean-kernel -aAd -L std
Preserving currently running kernel (6.1.57-gentoo-luxbook-2)
Legend:
[-] file being removed
[x] file does not exist (anymore)
[+] file being kept (used by other kernels)

Remove other 6.1.53-gentoo-r1-x86_64 (unwanted)? [Yes/No]
Remove other 6.1.53-gentoo-r1-luxbook-1 (unwanted)? [Yes/No]
Remove other 6.1.53-gentoo-r1-luxbook-2 (unwanted)? [Yes/No]
Remove other 6.1.53-gentoo-r1-luxbook-2.old (unwanted)? [Yes/No]
* Removing kernel other 6.1.53-gentoo-r1-x86_64 (unwanted)
 [-] /boot/vmlinuz-6.1.53-gentoo-r1-x86_64
 [-] /usr/src/linux-6.1.53-gentoo-r1
 [-] /lib/modules/6.1.53-gentoo-r1-x86_64
 [-] /boot/System.map-6.1.53-gentoo-r1-x86_64
 [-] /boot/config-6.1.53-gentoo-r1-x86_64
* Removing kernel other 6.1.53-gentoo-r1-luxbook-1 (unwanted)
 [-] /boot/vmlinuz-6.1.53-gentoo-r1-luxbook-1
 [x] /usr/src/linux-6.1.53-gentoo-r1
 [-] /lib/modules/6.1.53-gentoo-r1-luxbook-1
 [-] /boot/System.map-6.1.53-gentoo-r1-luxbook-1
 [-] /boot/config-6.1.53-gentoo-r1-luxbook-1
* Removing kernel other 6.1.53-gentoo-r1-luxbook-2 (unwanted)
 [-] /boot/vmlinuz-6.1.53-gentoo-r1-luxbook-2
 [x] /usr/src/linux-6.1.53-gentoo-r1
 [-] /lib/modules/6.1.53-gentoo-r1-luxbook-2
 [-] /boot/System.map-6.1.53-gentoo-r1-luxbook-2
 [-] /boot/config-6.1.53-gentoo-r1-luxbook-2
* Removing kernel other 6.1.53-gentoo-r1-luxbook-2.old (unwanted)
 [-] /boot/vmlinuz-6.1.53-gentoo-r1-luxbook-2.old
 [x] /usr/src/linux-6.1.53-gentoo-r1
 [x] /lib/modules/6.1.53-gentoo-r1-luxbook-2
 [-] /boot/System.map-6.1.53-gentoo-r1-luxbook-2.old
 [-] /boot/config-6.1.53-gentoo-r1-luxbook-2.old
Removed 4 kernels

edit: it'd be nice if it could also clean up my UKIs below the EFI folder though...

luxbook ~ # ls /boot/EFI/Linux/
linux-6.1.53-gentoo-r1-luxbook-1-d31be9dfcc49461fbca1245249ac3ec9.efi  linux-6.1.53-gentoo-r1-x86_64-d31be9dfcc49461fbca1245249ac3ec9.efi
linux-6.1.53-gentoo-r1-luxbook-2-d31be9dfcc49461fbca1245249ac3ec9.efi  linux-6.1.57-gentoo-luxbook-2-d31be9dfcc49461fbca1245249ac3ec9.efi
linux-6.1.53-gentoo-r1-x86_64-Default.efi

[MocioF]

@luxifr I had the same issue. It seems the problem is that you have a /boot/loader dir that could have been created running make install in kernel sources' dir with installkernel built with systemd use flag.
Even if I'm on a systemd profile, I re-emerged installkernel with -systemd.
I use rEFInd and I mount the EFI partition under /mnt/ESP
I am not sure if this is the case, but I resolved removing /boot/loader; then eclean-kernel -l sees my kernels and works as expected.

[LtdJorge]

@MocioF yes, this seems to happen when there are directories inside boot, and they may be referencing deleted entries. I had used systemd-boot before, and then switched to grub2, so the directories left behind were the ones triggering the issue. Upon removal, eclean-kernel works fine.

Edit: for the record, the directories I had to remove are /boot/{EFI, loader} and a /boot/8aadfed060044c698c387af528470739 which was being referred to by the files in loader. This last one, I had removed before getting this error, because I had another error saying "Is a directory" for that directory.

[Nowa-Ammerlaan]

There are several different things mentioned in this issue. But the efistub problem is fixed by: 765ca5f

[ndjlj]

I have this same exact issue:

SystemError('No vmlinuz found. This seems ridiculous, aborting.')

Some data:

sudo eclean-kernel -p
eclean-kernel has met the following issue:

  SystemError('No vmlinuz found. This seems ridiculous, aborting.')

If you believe that the mentioned issue is a bug, please report it
to https://github.com/mgorny/eclean-kernel/issues. If possible,
please attach the output of 'eclean-kernel --list-kernels' and your
regular eclean-kernel call with additional '--debug' argument.

eclean-kernel --list-kernels
modules-only 6.6.41-gentoo-dist [None]
- modules: /lib/modules/6.6.41-gentoo-dist
- build: /lib/modules/6.6.41-gentoo-dist/../../../src/linux-6.6.41-gentoo-dist
- last modified: 2024-08-11 21:44:47
modules-only 6.6.35-gentoo-dist [None]
- modules: /lib/modules/6.6.35-gentoo-dist
- last modified: 2024-07-25 21:21:55
modules-only 6.6.32-gentoo-dist [None]
- modules: /lib/modules/6.6.32-gentoo-dist
- last modified: 2024-06-18 23:36:18
modules-only 6.6.30-gentoo-dist [None]
- modules: /lib/modules/6.6.30-gentoo-dist
- last modified: 2024-05-18 20:57:43

ls /boot
amd-uc.img                 initramfs-6.6.30-gentoo-dist.img  System.map-6.6.35-gentoo-dist
config-6.6.30-gentoo-dist  initramfs-6.6.32-gentoo-dist.img  System.map-6.6.41-gentoo-dist
config-6.6.32-gentoo-dist  initramfs-6.6.35-gentoo-dist.img  vmlinuz-6.6.30-gentoo-dist
config-6.6.35-gentoo-dist  initramfs-6.6.41-gentoo-dist.img  vmlinuz-6.6.32-gentoo-dist
config-6.6.41-gentoo-dist  intel-uc.img                      vmlinuz-6.6.35-gentoo-dist
EFI                        System.map-6.6.30-gentoo-dist     vmlinuz-6.6.41-gentoo-dist
grub                       System.map-6.6.32-gentoo-dist

[Nowa-Ammerlaan]

It's probably auto-detecting your layout wrong. Please try setting the layout explicitly, and/or clean up directories belonging to systemd-boot if you are using grub.

[ndjlj]

@AndrewAmmerlaan

Thank you. Passing layout explicitly did the job.

eclean-kernel --layout std

[tsukasa1234567]

Just hit the same bug, passing -L std also fixed it for me, would you like more information to improve the auto detection or should I leave myself a note for future reference?

[Nowa-Ammerlaan]

Just hit the same bug, passing -L std also fixed it for me, would you like more information to improve the auto detection or should I leave myself a note for future reference?

If autodetection fails then you probably have some BLS type 1 or 2 layout files/directories left over. If you remove from your /boot and/or /efi everything that does not have to be there then autodetection will probably work again.