I cannot boot into Garuda anymore. GRUB shows no “Garuda snapshots” option (and I don’t remember how long this happens already).
Maybe the boot problems are a software bug after update. Do you know how to manually boot Snapper snapshots from GRUBs command line? (Ugh, US keyboard layout!) I only know it with Live USB booting but which is inconvenient. Is there a way to re-enable Garuda snapshots during boot?
I Garuda-updated yesterday successfully (11GB update). Since the beginning, I have update problems due to storage memory. I am always using a self-written memory check and cleanup script (enforcing 1.5GB free storage after subtracting the Pacman indicated storage requirements) before it updates. It prevents updates from breaking the system with out of storage crashes.
Dolphin showed, the disk was not full when I powered off. From my windows dual boot it confirms, there are 7GiB free on the Garuda (root) partition.
The first bad omen during boot is a Journal Flush which takes a minute and fails (by own words) due to insufficient storage.
Then, the systemd tasks fail to start during boot. From a TTY (CTRL+ALT+F2), I ran systemctl status <task-name> (using bluetooth.service as example) which confirmed that the given reason is insufficient storage.
It also shows a bug: it shows failure of a “nofail” fstab entry. I don’t remember this happening previously. (I successfully commented that entry out using Windows.)
Have you tried to boot up the live ISO, Mount your mian drive with dolphin or CLI. Then open btrfs assistant or snapper an restore your prior save point.
Thank you for encouraging me. I saw no other way either. I had to try around with a new Live USB and it took hours.
So, it only works halfways. It actually didn’t work initially. Only after deleting all snapshots newer than the restored one, then it successfully booted.
As it concerns the “Garuda Linux Snapshots”, they can be re-enabled in the BTRFS assistant → Snapper Settings → systemd Unit Settings: Snapper boot enabled. It seems, the snapshot mechanism is unreliable: boot success depends on newer snapshots as well.
EDIT: Btw, the systemd task failures are somehow related to not being able to write and read certain files, for example with the garuda-pacman-snapshot-reject.service. Some tasks just exit with exit-code due to not finding or writing files.
My problem now, I cannot garuda-update anymore because there is not enough storage (I have 12.8 GiB left (48GiB in total available), the update needs 13.6 + 1.5 GiB, where every day adds more than one GiB of updates). I have only 4 heavy but important snapshots left.
I will try to partially update the system and reboot (for testing) until everything is updated .
Isn’t there an automatic way to do memory-managed sequential (instead of big-bang) updating in 2025? I imagine, this is like updating computers 3 decades ago.
If you read the arch docs you can add a modifier to updates so that old versions arn’t kept or a single version or the catch is cleared on running or both.
At the end of the day arch is arch, it won’t ever really change.
This is weird. Well, I removed some of the remaining heavy snapshots so that I could do a new garuda-update. After the update, I rebooted directly afterwards and everything boots fine. I don’t understand what happened.
Well, yesterday, after the update, I did not reboot and install additional software. Maybe, this caused problems. I couldn’t play a game with Wine, I installed umu-launcher and installed portproton which was able to run GOG Galaxy. But neither of them could run the game. The portproton thing installed stuff automatically in the background. This could also have made problems.
I recommend that you read up on how btrfs and snapper work.
Sure, you can try everything to run garuda on this mini-partition - but it would make much more sense to enlarge the partition, otherwise you’ll run into the same problem again at some point.
Thank you for your advice. You mean Heroic Games Launcher? That’s the first thing, I always try, but unfortunately, it doesn’t. I posted the incompatibility in their support channel on Discord (maybe only concerns the GOG version?).
Thank you. Unfortunately, I cannot enlarge this partition further. It was 40GiB initially (because I thought it would be sufficient, reading about 30GiB on the Website).
Any chance, I could store the snapshots on a partition separated from the updated partition?
There is much unused space on my hard drive but is it actually possible to successfully move the root partitions to a different place? I already had multiple problems after I enlarged the root partition.
I am not familiar with Snapper, but surely there is a way to control the number of snapshots kept?
As mentioned elsewhere, I don’t use snapper or snapshot creation. I think it’s overkill to create a new snapshot for every small install/uninstall/update of a package.
On my desktop computer, the root partition has exactly 50GB. With more than 2000 packages installed, it is only half full. I use a pacman hook that reduces the cache to the last 2 packages and cleans it automatically after every update. Only 30GB on the laptop. As long as you keep an eye on it and empty the pacman cache regularly, there are no space problems.
@Elmar
It is certainly possible to move the partition, but you should know exactly what you are doing.
For inexperienced users, this can quickly end in chaos and result in data loss.
Sometimes it is better to start from scratch, i.e. to set up all partitions again, than to fiddle around with them. Or you can install an additional drive.
Your advice is welcome.
Like magic for me. I’ve hesitated with daily updates due to bandwidth and time costs of daily updates (as well as higher probability of receiving a broken update), but not being able to update is possibly worse.
A good fit for the introductory section: I am using the KDE version and it came with snapper integrated, I have 2450 installed items (according to bauh) with 48GiB available in BTRFS. It’s true, that the total size of all installed files is possibly below 20GiB. I am limiting the temporal snapshots to 10 per Snapper settings (and my pre-update script is cleaning old ones automatically up to a limit) but depending on snapshot size, the storage currently only suffices for 6 to 8 important snapshots (I guess for 2 weeks) with empty Pacman cache. I gonna disable my useless pacman pre-transaction hook. It would clear the cache after passing my scripted memory check. There are frequent updates lately, and I wish the big ones (like Google fonts) would be less frequent.
And btw, I used the KDE Partition Manager back then (2023) to remove and recreate the swap partition and enlarge the root partition, which did not modify the /etc/fstab properly and did not use the btrfs interface properly. Now I am using GParted but there is my fear as I do not know all the metadata that depend on the absolute partition location.
When my will is ready, I’ll try to create a new root partition elsewhere with bigger space to migrate it.
You are not the first person to run into this problem, and you won’t be the last. Off the top of my head, I can think of topics like “root full - cannot boot anymore”, “not enough free space after update”, “cannot boot after update - disk full”, “cannot boot - snapshot doesn’t work - not enough free space”, etc. You just had to use the search function
If you delete files which are captured in a Btrfs snapshot to create more free space, then the space is not released until you delete the snapshot.
You can also exclude certain directorys from snapshots to save space (or deactivate snapper completely if you don’t need it).
If you enlarge the root partition, then you have to expand btrfs afterwards. The most important thing to do is backupbackupbackup.
Then you should consider whether a rolling release distribution is really right for you. At worst, an update takes a few minutes.
The less often you do it, the longer it will take, of course, and the error rate will increase instead of decreasing as you assume. It is a fallacy that less frequent updates will reduce the error rate. Because even on the day of the update, you will still have completely fresh packages that may have been released minutes ago and may be broken.
If you want to use snapshots, 48GB is very little storage and therefore labor intensive, because you have to keep an eye on it and fiddle with it all the time. I would use at least 100GB, better 150GB or more for the root partition. Or, as many people suggest today, use an entire drive for everything, including /home.
Interesting. I’ll keep the 100GiB in mind. I was mainly afraid of the chore that comes with each update. But with more frequent updates it’s less per update. I hope that a future is possible with automatic update management.
It might be helpful to recommend these 100GiB to new people. I had read about at least 30GiB of storage when I chose the KDE version with Snapper.
I chose Garuda 2023 because of multimedia support. The multimedia, e.g. gaming, support (and the Forum) is great indeed. Garuda also has some user-friendly additions.
I also like to have the newest software and the newest development technology. KDE is sometimes better than Windows. I made bad experience with Ubuntu & Debian in that regard.
I just don’t know which distribution or OS is better than Garuda (I already have Windows but use it very rarely when it doesn’t work with Linux). Fedora is certainly not (bleeding edge).
Explaining is better than asserting, so: I think of each package as a stochastic process in “unproblematicness”. The more I sample it, the more unproblematic package versions I will uncover. When binary, the unproblematicness is a geometrical distribution. Bigger updates sample more packages at the same time (with individual stochastic process). The number of simultaneous packages is bounded. The probability of unproblematicness eventually would depend on the sampling count. But new features and patches are more worth an update.
So if very frequent updates ease the chore and mitigate the storage problems, I am doing it. I gonna updating every day I think of it as Garuda user and let’s hope, it will be good.
When i wake up I run a update reboot if any issues i use a snapshot go back an then wait 3-5 days then update. I also sneak in a update before I log off or shutdown at night if I remember. but the main one is in the morning.
As for other options opensuse slowroll only updates one a month an uses simi tested updates from tumbleweed (rolling os).
What tedious chore do you mean? Open a terminal, type upd, press ENTER, type the sudo password, press ENTER twice, wait for it to complete, and then, in the worst case, reboot? I do that every morning.
If you want to make yourself something to eat, you have to take the pot out of the cupboard, turn on the stove, etc. My point is that regular updates are simply essential when using a computer.
And no, I personally don’t want automatic updates. I want to know what is changing on my system and why.
Windows, no matter what version, is about as far away from KDE and Linux in general as Sagittarius A* is from our Earth - light years.
As I wrote before, I have no idea how to use snapshots. The 100-150GB I mentioned is not a healthy, optimal size for every user. I’m sure the cracks here can say better than that if you ask for.
EDIT:
To avoid problems with Snapper and snapshots, I recommend that you take a look at the configuration in /etc/snapper/configs and the corresponding article in the Arch wiki, as well as the man page.
Auto-translation is a dangerous sword.
It says, the chore is less when updating more frequently.
The chore is just to manually remove snapshots and clear the cache, if my automatic script got to its allowed removal limit, and, if not enough, eventually do multiple manual partial updates, reboots and snapshot removals sequentially before garuda-update to get the system updated. It can take over half an hour.
Now, I try to update when I can and don’t forget. For example I’ve had no Internet access since yesterday and now got a password for the office network.
.
