Safely update with garuda-update

Thank you for your time to answer.

Merely my experience. You were kind and linked my original post with the root partition problem which shows the error output I got.
It only tells me, it could not write the binaries (or other files) to the location. I looked at the space usage of the partition and in the live USB session when I saw, I could not write anything anymore in the partition (“No space left on device”), I assumed, it was a memory insufficiency problem.

That isn’t true, Pacman is able to gracefully fail to update. If the update fails, no packages will be updated and no packages will be removed.

Right, most of the time, garuda-update failures (e.g. due to access rights, internet connection or dependencies) do not break anything and exit cleanly. But it actually happened in every update attempt in the past two weeks that my system was in a broken state after the update process failed with writing errors. Directly afterward, Kernel files were missing, important software could not be started anymore, such as Konsole and settings.

[…] fix the problem that prevented the update from succeeding, and then take the update […]

Indeed, I did that at first, I tried cleaning up space, and it made everything worse. It finally caused a state (I removed almost every snapshot for making space) where I initially could not boot into any snapshot or backup subvolume. As you say, deleting backup subvolumes and package cache is much more effective.

The two remaining good snapshots caused a Samba SMB / NMB failure symptom before the login screen. It showed me 4GiB free (after I had already done sudo btrfs filesystem resize max /), I don’t know why, maybe allocated by another process like Snapper but unused, when it told me “No space left on device” during write attempts.

The good news is, the good backup subvolume booted after I cleared space in a live USB session.

Snapshots typically take up very little space, […]
In your other thread you mentioned you set it to 10 snapshots? Try changing it to 20. :man_shrugging:

Thanks. That’s a helpful tip, I will try it. Indeed, I was afraid of space usage.
And still, it created at least 5 snapshots within 7 minutes because removing one application in Pamac or Discovery creates two new snapshots. I read that at least one other person had a problem with snapshot management and replaced good snapshots with bad ones, could not boot anymore and gave up.
Of course, people say, they should make a backup (while sthg. like experience or hardware access holds them back), but it’s certainly more usable to make people aware of the snapshot issue in relevant cases. I guess, restoring a full partition backup in an unbootable system takes more effort than just selecting a snapshot in the bootloader.

You should not be installing or updating any kernels with Discover[y], […]

I will remember that. Fortunately, it worked without errors or such.

Cheers.