Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
gabrielgg opened this issue Mar 5, 2021 · 13 comments

Comments

@gabrielgg
Copy link

# 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
Copy link

lekto commented Apr 10, 2021

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
Copy link

Tatsh commented Apr 11, 2021

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
Copy link

matteganau commented Sep 11, 2021

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

@Nowa-Ammerlaan
Copy link
Contributor

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

@luxifr
Copy link

luxifr commented Nov 4, 2023

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
Copy link

MocioF commented Jan 27, 2024

@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
Copy link

LtdJorge commented Feb 17, 2024

@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
Copy link
Contributor

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

@ndjlj
Copy link

ndjlj commented Aug 12, 2024

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
Copy link
Contributor

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
Copy link

ndjlj commented Aug 13, 2024

@AndrewAmmerlaan

Thank you. Passing layout explicitly did the job.

eclean-kernel --layout std

@tsukasa1234567
Copy link

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants