Fixing a full system disk is harder than it needs to be

Problem

I have a Kinoite system with separate system and userdata. (lvm volumes and ext4 on top.)
Due to the kind of deployment,
I expected the system disk space to stay relatively constant.
I gave the rootfs LV 20GB.
I underestimated the growth.
Thing went full when upgrading.
It was unnecessarily complicated to fix the situation.

Cause

The process to decrease userdata partition and increase system partition size is convoluted, does not work with mounted FS’ and in the GUI warning could as well be a FIX button.

On Kinoite/Silverblue the system partition has multiple active mountpoints, some of them with readonly option. resize2fs refuses to online-resize when one mountpoint has ro.

The integration of storage layers is bad.
If I want to shrink/grow a filesystem on LVM on LUKS on GPT,
I have to use 4 different tools to match sizes in every one of these layers and have to do them in the right order.

Workarounds

Not for the general case, but in this instance
I unmounted home, shrank it, reduced the home LV, increased the root LV, then rebooted and

modified the grub kernel commandline on boot to add init=/bin/bash,
(to have a system where nothing really touches the disk except kernel stuff. Because nobody ever ported runlevels to systemd targets properly.)
Then I remounted all root mounts to rw, so resize2fs doesnt complain.
Then resized the rootfs to the LV size. (PATH isnt set when bash is init, you have to use absolute path)
Then remounted everything ro.
Then force rebooted.

I’m not a Kinoite user, but… doesn’t it use btrfs by default?

1 Like