Kernel backups in /boot/efi/

English Install/Boot/Login
1

I installed Tumbleweed with the default configuration, which created /boot/efi/ with 1 GB.
Now I’ve discovered that the kernel backups are stored there, which means that space is very limited…

436M /boot/efi/opensuse-tumbleweed/6.19.5-1-default
296M /boot/efi/opensuse-tumbleweed/6.19.5-2-default
156M /boot/efi/opensuse-tumbleweed/6.19.3-1-default
3,2M /boot/efi/EFI/opensuse
2,1M /boot/efi/EFI/BOOT
88K /boot/efi/loader/entries
4,0K /boot/efi/loader/random-seed
4,0K /boot/efi/loader/loader.conf

Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/nvme0n1p1 1022M 893M 130M 88% /boot/efi

Is there a guide on what I can do? Is it possible to store the kernel backups somewhere else, or is there a good solution for enlarging the partition without risking my system?

3 Likes
2

I’m not sure of the “official” solution, but perhaps you could obtain bootable gparted live USB image and increase boot EFI.

I’ve actually got into trouble with 2GB when trying more than one OS, so I would suggest at least 4GB.

I recently used gparted to increase my boot EFI from 500MB to 4GB, that worked without any issue. I also reduced the size of the adjacent partition - which is ext4, but gparted is reported to be able to edit btrfs too. I guess there’s a chance this could go horribly wrong, so do a backup of any data first.

You might also switch to good old grub2, which requires far less space. However, I’m uncertain of the correct procedure to make the switch - especially given the default bootloader has recently changed and may even be changing again. I do greatly prefer grub2 at this point.

1 Like
3

To switch to using grub2-efi…
sudo editor /etc/sysconfig/bootloader

Change LOADER_TYPE to LOADER_TYPE="grub2-efi"
then save and exit when done.

Reinitialize the bootloader…
sudo update-bootloader --install --config

This will regenerate /boot/grub2/grub.cfg and classic GRUB menu entries will now be used instead of the BLS fragments in /boot/loader/entries/.

At this point you can clean up /boot/loader/entries if desired…
sudo rm -r /boot/loader/entries/*

3 Likes
4

Curious regarding gparted, when modifying the size of the boot EFI, do you prefer the live usb image for any particular reason? I was also looking to modify my boot EFI size without reinstalling my entire OS. gparted comes as a live iso and application, and was wondering if there are advantages to the live iso.

1 Like
5

Because else you are changing the legs of the table you are sitting on.

5 Likes
6

Exactly so.

Gparted will refuse to alter a mounted partition. However, if /boot/efi can be unmounted, and if there is space adjacent to it that isn’t part of a mounted partition, then you should be able to alter that space and expand it into it. Given you used the default configuration, this is unlikely to be the case.

If you have another Linux installed elsewhere on the same machine, you could boot into that. That’s how I moved to having 4GB, I booted into a alt/backup copy of my existing system, then altered the idle main copy.

2 Likes
7

One other caution I’d like to make, (learned from when was I recall trying GRUB2 with BLS last year), was that when I decided to switch back to classic GRUB, the EFI bootloader hadn’t been fully installed. As a result, I had to boot from a live OS and chroot into my system to reinstall GRUB for UEFI…
sudo grub2-install --target=x86_64-efi --bootloader-id=opensuse --efi-directory=/boot/efi, so might be worth invoking explicitly before rebooting. (I didn’t investigate how this came about at the time.)

1 Like
8

Correct me if I am wrong. If I get what you are putting down, then based on how I installed my system, even if I got the live iso I would not be able to edit /boot/efi?

1 Like
9

You do seem to be off on the wrong track.

By booting from a gparted live ISO you would boot into an environment where your normal drives and partitions are not mounted, so you will be free to manipulate them.

That said, to increase the EFI partition, you will probably have to also use gparted to reduce the size of whatever is adjacent to it. So you have to be happy to do that. Gparted can adjust the size of partitions without data loss, so this is feasible/doable.

In my own case I booted into an alternative OS, which is pretty much the same as using a live ISO. I then reduced the size of the partition adjacent to boot EFI, then I enlanged the EFI partition. This all went quite smoothly, but you have to be sure of what you are doing.

If you’re not confident in doing this kind of fiddling and haven’t really done much beyond installing your OS, then it may well be easier to just reinstall and manually setup a new partitioning scheme.

If you’re not so interested in systemd-boot or grub-bls, it may be easier to switch to using grub2 which doesn’t use as much space as systemd-boot or grub-bls. But you might like to request someone provide a precise series of steps. I can’t help with that, I haven’t tried switching boot loaders recently.

I would add, because OpenSUSE is going through some changes to boot loader, the installer hasn’t caught up, and some unexpected issues are also causing changes in direction. Unfortunately things are a bit bleeding edge at the moment, installation is not normally this painful.

2 Likes
10

Refer my earlier reply.

1 Like
11

You did not have to move the result so the free space comes at the beginning (direct after the EFI partition)?

BTW, I assume that advising without having seen what the present partitioning is, is a bit dangerous.

1 Like
12

Thanks for the clarification, that really helped.

If you are referring to how I partitioned my system, you can look here. That being said, I may have veered the original post off topic, so I’ll stop now.

1 Like
13

I tried your procedure on a relatively modern PC I use for experimentation. After I made one addition and one correction it worked.

When I did the above step I got:

sputnik3:~ # update-bootloader --install --config
target = x86_64-efi, update default location = 1
+ /usr/sbin/shim-install --config-file=/boot/grub2/grub.cfg
/usr/sbin/shim-install: line 251: /usr/sbin/grub2-probe: No such file or directory
efi_distro_dir=opensuse
efi_order=0003,0001,0002,0004,0005,0006
efi_entry.num=0003
efi_entry.file=EFI/OPENSUSE/SHIM.EFI
efi_entry.name=openSUSE Boot Manager

I needed to install grub2-efi.

I also got another error:

sudo rm -r /boot/loader/entries/*
rm: cannot remove '/boot/loader/entries': No such file or directory

I think that’s just a typo.

I think the correct steps are:

sudo editor /etc/sysconfig/bootloader   # I used vi as my editor
sudo zypper install grub2-x86_64-efi
sudo update-bootloader --install --config
sudo rm -r /boot/efi/loader/entries
sudo grub2-install --target=x86_64-efi --bootloader-id=opensuse --efi-directory=/boot/efi
sudo reboot

On booting, I now see the old grub2-efi menu.

I probably should have done a sudo efibootmgr -v to check for opensuse entry being set to \EFI\OPENSUSE\GRUBX64\EFI as well, but I forgot that until after rebooting.

In the long term it might still be a good idea to enlarge boot-efi to 4GB (on this particular machine, my current boot-efi is above 1GB due to me untidily keeping a few kernels around).

2 Likes
14

FWIW, yet another “how to”…
https://www.reddit.com/r/openSUSE/comments/1qkkm2x/how_to_switch_from_grub2bls_to_grub2efi_manual/
(Subtle variations to suit particular situations, but essentially the same.)

4 Likes
15

(reddit.com is blocked by my hosts file)

Does this reinitialization move kernels and initrds from the ESP filesystem to the filesystem containing /boot/?

1 Like
16

Interesting question. I just took a look at the system I experimented with and it doesn’t look right compared to my own desktop which has always been grub2. The experimental system does boot, but the following looks wrong:

# ls -l /boot/
total 12
drwx------. 5 root root 4096 Jan  1  1970 efi
drwxr-xr-x. 1 root root   84 Mar 10 08:11 grub2
lrwxrwxrwx. 1 root root   23 Nov  8 16:37 initrd -> initrd-6.17.7-1-default
lrwxrwxrwx. 1 root root   24 Nov  8 16:37 vmlinuz -> vmlinuz-6.17.7-1-default

# find /boot -name 'initrd*' -ls
      115 140112 -rwxr-xr-x   1 root     root     143474662 Mar 10 08:15 /boot/efi/opensuse-tumbleweed/6.19.6-1-default/initrd-35768895c93a5310812b1ddebc30168b59ee9539
   179214      4 lrwxrwxrwx   1 root     root            23 Nov  8 16:37 /boot/initrd -> initrd-6.17.7-1-default

From interesting question to good question.

1 Like
17

No. Reinitializing the bootloader only regenerates the GRUB configuration and boot entries. It does not move the kernels or initrds.

When switching back to classic GRUB (grub2-efi ), the kernel packages will place the kernel and initrd under /boot , which is the location used by classic GRUB. If you want them regenerated immediately, you can simply reinstall the kernel package after switching the loader type.

It’s generally not recommended to move the files manually. Let the kernel packaging scripts recreate them in the correct location. Once the system is using classic GRUB, any old kernel or initrd copies on the ESP can then be removed if desired.

1 Like
18

I wonder if Tumbleweed should have a new default of 4 GB? Is there a bug about this?

4 Likes
19

I did:

zypper install --force kernel-default-6.19.6

The initrd and kernel still seem to be under /boot/efi:

sputnik3:~ # grep LOADER /etc/sysconfig/bootloader 
LOADER_TYPE="grub2-efi"
sputnik3:~ # ls -l /boot/ /boot/efi/opensuse-tumbleweed/6.19.6-1-default/
/boot/:
total 12
-rw-r--r--. 1 root root    0 Mar 12 08:35 do_purge_kernels
drwx------. 5 root root 4096 Jan  1  1970 efi
drwxr-xr-x. 1 root root   84 Mar 10 08:11 grub2
lrwxrwxrwx. 1 root root   23 Nov  8 16:37 initrd -> initrd-6.17.7-1-default
lrwxrwxrwx. 1 root root   24 Nov  8 16:37 vmlinuz -> vmlinuz-6.17.7-1-default

/boot/efi/opensuse-tumbleweed/6.19.6-1-default/:
total 296520
-rwxr-xr-x. 1 root root 143474662 Mar 10 08:15 initrd-35768895c93a5310812b1ddebc30168b59ee9539
-rwxr-xr-x. 1 root root 143475808 Mar 12 08:36 initrd-e6baaf4630d62e550620e818045f07db493b1b73
-rwxr-xr-x. 1 root root  16680816 Mar  5 19:09 linux-b67afcf34244e78002db3aefc871d0dc6bd56e7f

I guess forcing an install of kernel-default is not the correct way to “reinstall the kernel package”?

1 Like
20

The issue appears to be that the kernel package still thinks the BLS layout is active, so its install scripts continue placing the kernel and initrd in the ESP under the BLS directory structure.

After changing the LOADER_TYPE, you invoked
sudo update-bootloader --install --config?