which confirms the system is still operating in BLS mode. Speculating a bit here: As long as kernel-install detects a BLS layout on the ESP (for example directories such as /boot/efi/loader/entries/ or the existing /boot/efi/opensuse-tumbleweed/ kernel directories perhaps), it will continue installing kernels there. Hopefully, others can chime in here to clarify further.
OK, thanks. If no further suggestions come in, sometime tomorrow I might see if I can clear out the current folders and files and try again. It’s an experimental system, worse case I can reinstall it. It’s possible some past experiment is fouling things up (for example, it was dual booting with cachos until recently, and I also shuffled some drives around).
I have the same problem. I reinstalled my system a few weeks ago with only one EFI partition (300 MB, dual-boot with Windows, nvme0n1p01) with full disk encryption. The partition filled up shortly after.
Then, a week ago, I reinstalled the system with a dedicated EFI partition (500 MB, nvme0n1p07). Now this partition is also full. I’m not sure if I can increase the partition size.
What can I do now? Should I change the Grub type, as described above?
I had the same issue with the /boot/efi partition, where it was filling up. My resolution was to shrink the partition to its right by 3GB from the left, and expand the /boot/efi partition into that space.
It worked with no issue, but I agree that it makes sense to increase the default partition size to 4GB for /boot/efi/, since this seems to be a fairly regular occurrence.
It’s probably safer to increase the size of /boot/efi, as most recently described by @crestless1624, and also discussed and described earlier.
I can’t seem to successfully switch back to grub2. It could be that I’ve broken my system in a way that prevents the suggested procedure from working. Hopefully someone else will chip in with a can’t fail method.
I think I’ve managed to get grub2-efi properly installed. I compared what was installed for grub2 on my normal TW desktop versus my experimental TW system.
I can’t say I’m confident in the steps taken and whether they are all necessary. There may be a simpler less complex alternative procedure. Having cleaned/modified /boot/efi, I cannot use snapper to revert and try something else.
Here is the totality of what I tried (I worked as root, so these will need sudo in front of them if you’re not root):
editor /etc/sysconfig/bootloader # I used vi as my "editor"
zypper remove grub2-x86_64-efi-bls-2.14-5.1.noarch # Not sure it this is necessary
zypper install grub2-x86_64-efi
zypper install grub2-x86_64-efi-extras # Probably what I was missing earlier
update-bootloader --install --config
rm -r /boot/efi/loader/entries
grub2-install --target=x86_64-efi --bootloader-id=opensuse --efi-directory=/boot/efi
zypper install --force kernel-default-6.19.6 # Reinstall the current kernel # sets up /boot
The result looked promising:
sputnik3:~ # ls -l /boot/
total 140152
lrwxrwxrwx. 1 root root 42 Mar 13 09:08 config-6.19.6-1-default -> ../usr/lib/modules/6.19.6-1-default/config
drwx------ 4 root root 4096 Jan 1 1970 efi
drwxr-xr-x. 1 root root 84 Mar 13 09:08 grub2
lrwxrwxrwx. 1 root root 23 Mar 13 09:08 initrd -> initrd-6.19.6-1-default
-rw-------. 1 root root 143475725 Mar 13 09:08 initrd-6.19.6-1-default
lrwxrwxrwx. 1 root root 47 Mar 13 09:08 sysctl.conf-6.19.6-1-default -> ../usr/lib/modules/6.19.6-1-default/sysctl.conf
lrwxrwxrwx. 1 root root 46 Mar 13 09:08 System.map-6.19.6-1-default -> ../usr/lib/modules/6.19.6-1-default/System.map
lrwxrwxrwx. 1 root root 24 Mar 13 09:08 vmlinuz -> vmlinuz-6.19.6-1-default
lrwxrwxrwx. 1 root root 43 Mar 13 09:08 vmlinuz-6.19.6-1-default -> ../usr/lib/modules/6.19.6-1-default/vmlinuz
lrwxrwxrwx. 1 root root 49 Mar 13 09:08 .vmlinuz-6.19.6-1-default.hmac -> ../usr/lib/modules/6.19.6-1-default/.vmlinuz.hmac
lrwxrwxrwx. 1 root root 30 Mar 13 09:08 .vmlinuz.hmac -> .vmlinuz-6.19.6-1-default.hmac
After rebooting I checked the following which seems to look right:
I can’t recommend what I’ve done with any air of authority. I’ve only persisted in case it throws some light on the situation or flushes out a better procedure.
I decided it would be better to start over from scratch. I reinstalled everything yesterday and played it safe with the /boot/efi partition this time. But that really should be adjusted in the installer…
It is using detection heuristics. If it sees a folder on the EFI partition matching the system’s Machine ID, it assumes it should use the BLS layout, even if the main bootloader was switched back to Classic. Anyway you can check /boot/efi/ with ls /boot/efi/$(cat /etc/machine-id) /boot/efi/loader
and then move that directory to test eg rename it to <machine-id>.old. When it can’t be found you’ll get KERNEL_INSTALL_LAYOUT=other again.
Thanks, that didn’t find anything, but was a big clue anyway.
sputnik3:~ # ls /boot/efi/$(cat /etc/machine-id) /boot/efi/loader
ls: cannot access '/boot/efi/0253f2351d5a47670011623a690ebb2b': No such file or directory
ls: cannot access '/boot/efi/loader': No such file or directory
I did an strace of kernel-install and also compared my desktop to my experimental machine. The cause was the presence of /boot/efi/opensuse-tumbleweed/ or the empty 6.19.6-2-default directory under it…
So I had failed to track down and eliminate all traces of grub-bls. I think the final list of what to do is as follows:
editor /etc/sysconfig/bootloader # I used vi as my "editor"
zypper remove grub2-x86_64-efi-bls-2.14-5.1.noarch # Not sure it this is necessary
zypper install grub2-x86_64-efi
zypper install grub2-x86_64-efi-extras # Probably what I was missing earlier
update-bootloader --install --config
rm -r /boot/efi/loader/entries
grub2-install --target=x86_64-efi --bootloader-id=opensuse --efi-directory=/boot/efi
zypper install --force kernel-default-6.19.6 # Reinstall the current kernel # sets up /boot
rm -rf /boot/efi/opensuse-tumbleweed # Maybe this could be down earlier, but I did it last.
reboot
Note, this was a pretty standard desktop with an unencrypted ext4 root. If you have an encrypted laptop, or some other different kind of system, then the above may not be applicable.
I’m not completely out of the woods. Grub2-efi is booting fine and the system is working normally, but I do see a seemingly harmless warning that I do not see on my main desktop. When installing a kernel I see:
sputnik3:~ # grep LOADER_TYPE /etc/sysconfig/bootloader
LOADER_TYPE="grub2-efi"
sputnik3:~ #zypper install --force kernel-default-6.19.6
...
Retrieving: kernel-default-6.19.6-2.1.x86_64 (repo-oss) (1/1), 183.8 MiB
Checking for file conflicts: ...................................................................................................................................................................................[done]
ERROR: Bootloader not detected. /etc/sysconfig/bootloader has LOADER_TYPE="grub2-efi", but only "systemd-boot" or "grub2-bls" are recognized.
ERROR: Bootloader not detected. /etc/sysconfig/bootloader has LOADER_TYPE="grub2-efi", but only "systemd-boot" or "grub2-bls" are recognized.
ERROR: Bootloader not detected. /etc/sysconfig/bootloader has LOADER_TYPE="grub2-efi", but only "systemd-boot" or "grub2-bls" are recognized.
(1/1) Installing: kernel-default-6.19.6-2.1.x86_64 .............................................................................................................................................................[done]
%posttrans(kernel-default-6.19.6-2.1.x86_64) script output:
ERROR: Bootloader not detected. /etc/sysconfig/bootloader has LOADER_TYPE="grub2-efi", but only "systemd-boot" or "grub2-bls" are recognized.
ERROR: Bootloader not detected. /etc/sysconfig/bootloader has LOADER_TYPE="grub2-efi", but only "systemd-boot" or "grub2-bls" are recognized.
Running post-transaction scripts ...............................................................................................................................................................................[done]
Yes, as I mentioned earlier, kernel-install uses heuristics to detect whether any directory resembling a BLS kernel layout exists on the ESP. Good that you tracked down the cause and removed it.
I don’t think grub2-x86_64-efi-extras is necessary. I don’t have that package installed myself.