KDE-Linux: Managing Base System Updates

Help
1

I’m sure I’m missing something, but I can’t figure out how update management works in KDE-Linux. Using virt-manager, I created a virtual machine with a 40GB disk running KDE-Linux. As time goes by, system updates arrive, and as expected, they’re stored so that, in case of problems, you can boot the system using an older base image. So far, so good.

The problem is that after three system updates, the 40GB disk is almost full (about 6GB remains free). When a new update arrives, I can no longer install it because there isn’t enough disk space. I thought the older images would be deleted to free up disk space, but that didn’t happen. I assumed that the update process, upon detecting insufficient disk space, would first delete the oldest image to free up the disk space needed for the update, but that didn’t happen.
Assuming that perhaps the retention limit for base images was indeed three, I expanded the virtual machine’s disk by adding another 20 GB, which allowed me to perform the new update. However, when I rebooted the virtual machine, I noticed that the number of retained images had increased to four, as shown in the image:

KDE-Linux-boot-menu
KDE-Linux-boot-menu530×211 12.5 KB

Now I’m wondering if this is a problem with my installation, or if I misunderstood what they mean on the KDE Linux website here: Keep the System Up to Date - KDE Linux when they say:

(…) To save space, performing a system update will remove older versions as needed but never the currently running version. If you perform an update when the currently running version is the oldest one, the second-oldest version will be removed instead.

Thank you for helping me understand.

2

Nothing is wrong with your installation. KDE Linux applies base system updates through systemd-sysupdate, and the KDE Linux transfer configuration keeps up to four versions (InstancesMax=4). Older versions are only deleted when a new update is started and the count would go past that number, so moving from three to four after you enlarged the disk is expected, and the retention was never fixed at three. The “remove as needed” wording in the KDE Linux update docs refers to that limit, not to free disk space, which is why an update can still fail on a nearly full disk like yours. If you need to reclaim space manually, systemd-sysupdate has a vacuum command that removes older versions; I have not tested how that interacts with the updatectl wrapper, so treat that last part as a pointer to check rather than a verified step.

3

Thank you very much for the clear answer.

So, the “magic number” is four :grinning_face_with_smiling_eyes: . That’s good to know, even though disks these days are much larger than the one on my little test VM.

4

I’ve updated the installation instructions to recommend a larger disk for now.

But this exposes a failure point: what if you fill up your disk before the first time you perform an update? You could then realistically lack the space to download the new erofs image.

The A/B partition approach to image-based OSs avoids this issue, but we need to handle it in another way. https://invent.kde.org/kde-linux/kde-linux/-/work_items/516 has some discussion on the topic.