During newer upgrades, I am getting notified by Plasma about low disk space in /efi. I figured out that this was because of snapper snapshots filling it up (1 GB seems to be not enough). I did read a few posts that at least 4 GB should be used for future proofing the install.
Since I am trying to avoid a reinstall for this, is it possible to increase the size of /efi from 1 GB to 4 safely via something like parted live? is it recommended?
I have already taken a backup of my home directory to be on the safer side.
You did not provide any information about the layout of the disk (like fdisk -l and/or lsblk -f) but it is likely that the EFI partition was one of the first created and thus will be hemmed in somewhere at the begin of the device.
The snapshots don’t live in /boot , they are in /.snapshots . And, Henk is right, there is no way that you can expand the partition, and also about switching to grub2-efi
Reading the GParted documentation, you’ll have to boot “GParted Live” to see if, you can move the beginning of the encrypted LUKS partition to allow the EFI partition to be increased – there are some statements in the GParted documentation around this issue which suggest that, the chances of success are small.
Personally, I would reinstall Tumbleweed with the default EFI partition size.
<Live CD/USB/PXE/HD>
The snapshots don’t live in /boot , they are in /.snapshots . And, Henk is right, there is no way that you can expand the partition, and also about switching to
I will just go for a reinstall later then. The main reason I chose grub with bls, was the support for luks2 with argon2id. Now that systemd-boot is going to be the default, will it have full snapshot functionality?
Last time I checked, many features were missing from it and the wiki itself is pretty out of date about its current state. I do know that argon2id support is there though.
Guess I will opt for 4 gb on the next reinstall then. I think it would be better if the installer suggests at least 2 gb, when grub2-bls or systemd-boot is selected.
If your going to create it, then 2GB is probably enough, but 4GB is the best bet (firmware updates)… there maybe times you wish to keep some extra kernels…
The problem is how snapper & sdbootutil handles snapshots and kernels in Tumbleweed. It creates a Cartesian product of kernels and snapshots (N(kernels) *M(snapshots-for-initrd)). This takes a lot of space. To bring it down you need to reduce the number of either (or both).
With tumbleweed you’re basically stuck with at least 2 kernels (current and next - I don’t think it’s wise to remove working kernel until successfully booted into a new one), so one option is to limit the number of snapshots.
I tried to keep ~2 important ones. However it doesn’t work really, so if zypper dup shows a new kernel I remove all snapshots but the latest -pre and -post (zypper rm 100-110), since everything worked well for some time. Obviously I’m too lazy to fix the 512M size of my EFI partition so I do manual actions every time .
Immutable-OSes (MicroOS/Aeon/Kalpa) however work much better with sdboot & snapshots, since it’s at most 1 initrd / snapshot and kernels are shared. You can clearly see the difference in malcolmlewis’s post. And honestly, considering how well MicroOS works with snapshots & rollbacks I don’t understand snapshots feature in Tumbleweed at all. There is more than one way to screw up and it’s more common to mess with /etc or bootloader than to break some packages rendering system unusable (this of course only thanks to top quality of tumbleweed).
Probably this is also because I run MicroOS on embedded devices and a server where chances to brick it are much higher. Works amazingly well there.
Anyways, after thinking about /boot/efi size problem I decided to convert my laptop, Surface Pro 3 (and eventually gaming box) to MicroOS/Slowroll. It is not supported scenario, but seems to work (if you understand how it works, more or less).
Would probably be good to make this scenario supported… I first tried Kalpa on my new desktop couple years ago and switched to Tumbleweed after 2 days - I heavily rely on Firefox + KeePassXC and it was just too quirky to get them working there. But otherwise, it seems like a reasonable approach - starts with Tumbleweed, once you finished running zypper install to get missing parts of the system, “freeze” it and turn into immutable.
.