Can't boot Garuda

Its done already and it works. Im just not sure if I should create those entries back or not…

I can try tho… Or is it safer to just don’t touch anything anymore? Since it’s all working fine…

I read somewhere that the fstab file is only there to ease the boot (speed). So it shouldn’t be a problem… right?

So, the three missing volumes are now back in place, and sudo btrfs subvolume list / shows them like in the example from my computer?
If you do mount (just by itself) are they shown as mounted at the right places?
In my case (among all the other ones) it says

/dev/sda3 on /var/tmp type btrfs (rw,noatime,compress=zstd:3,space_cache=v2,subvolid=262,subvol=/@tmp)
/dev/sda3 on /var/cache type btrfs (rw,noatime,compress=zstd:3,space_cache=v2,subvolid=260,subvol=/@cache)
/dev/sda3 on /var/log type btrfs (rw,noatime,compress=zstd:3,space_cache=v2,subvolid=261,subvol=/@log)

of course your device will be different than sda3

use UUID, its better, belive me :slight_smile:

cat /etc/fstab
File: /etc/fstab
# /etc/fstab: static file system information.
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=B3B3-D44D                            /boot/efi      vfat    umask=0077 0 2
UUID=35075ddb-bcf7-47aa-a43a-e759a082af57 / btrfs subvol=/@,defaults,noatime,space_cache,noautodefrag,compress=zstd 0 1 #Modified_by_garuda-hotfixes(1)
UUID=35075ddb-bcf7-47aa-a43a-e759a082af57 /home btrfs subvol=/@home,defaults,noatime,space_cache,noautodefrag,compress=zstd 0 2 #Modified_by_garuda-hotfixes(1)
UUID=35075ddb-bcf7-47aa-a43a-e759a082af57 /root btrfs subvol=/@root,defaults,noatime,space_cache,noautodefrag,compress=zstd 0 2 #Modified_by_garuda-hotfixes(1)
UUID=35075ddb-bcf7-47aa-a43a-e759a082af57 /srv btrfs subvol=/@srv,defaults,noatime,space_cache,noautodefrag,compress=zstd 0 2 #Modified_by_garuda-hotfixes(1)
UUID=35075ddb-bcf7-47aa-a43a-e759a082af57 /var/cache btrfs subvol=/@cache,defaults,noatime,space_cache,noautodefrag,compress=zstd 0 2 #Modified_by_garuda-hotfixes(1)
UUID=35075ddb-bcf7-47aa-a43a-e759a082af57 /var/log btrfs subvol=/@log,defaults,noatime,space_cache,noautodefrag,compress=zstd 0 2 #Modified_by_garuda-hotfixes(1)
UUID=35075ddb-bcf7-47aa-a43a-e759a082af57 /var/tmp btrfs subvol=/@tmp,defaults,noatime,space_cache,noautodefrag,compress=zstd 0 2 #Modified_by_garuda-hotfixes(1)
UUID=cbcc43bc-0d8d-43c7-b09b-98fcd238d14e /mnt/sda1 auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=sda1 0 0

I could agree that a causal user may not understand the significance of these directories. Hopefully a lesson learned here is that deleting things without understanding what they are is an easy way to break stuff.

Your system must have these directories, however if they are missing I believe it will just re-create them on its own. The reason you were not able to boot is because they are set up in fstab as mount points, and if a mount you have set up in fstab fails at boot then the boot itself will fail, unless the mount options specifically allow the mounts to be optional.

The reason these directories are included in /etc/fstab in the first place is because they are meant to be mounted on their own dedicated subvolumes. The reason for that is because otherwise everything in /var/cache, /var/log, and /var/tmp would be snapshotted along with the rest of the root subvolume every time a system snapshot is created. This will unnecessarily waste disk space, potentially quite rapidly, because all the temporary files contained in these directories will be stored on the disk indefinitely, until you delete those snapshots.

All that to say: your effort to save disk space has backfired in a dramatic way.

It seems insane that some post you found online would instruct you to delete subvolumes off your system. Can you please double-check this? Now that you have access to your system again, post into the thread:

sudo btrfs subvolume list /

Please also post the output of:


I will as soon as I’m back home.

Well I mean I’m used to delete huge files (like office setup) on windows and see the free space on disk increase. This wasn’t happening here. I did some research and someone actually posted it as something to do to gain space. It even said it was better then use some CCleaner alternative software…

I’m a casual Linux user but I’m not all that dumb tho (even if I agree, it looks like it tho :rofl:)

But when I saw it was cache and tmp stuff, I believed it wouldn’t be that bad. My mistake. Lesson learned.

I do learned something else tho. If u have a Linux problem, people are far more willing to help you out than on MS. Thanks guys.

I didn’t not inserted / mount or so those entry back. I will try to do so since it seems important somehow. I’ll give you feedback next.

1 Like

Cache and tmp contents can be removed quite freely as far as I know, just their volume and mount point is better left alone. Log I would clean less often and more carefully. Wiping everything in there won’t break the system, but for instance I often refer to the pacman.log if e.g. I suspect some problem with a recent upgrade, or maybe I didn’t notice some warning or I forget installing some package months ago.
Same with the system “journal”.
By the way, when you do a garuda-inxi, look at the install date. Surprise.

If you are low on disk space you’ll probably find cleaning the package cache effective, old package versions accumulating there can get huge. That can be automated, there’s instructions at Pacman#Cleaning_the_package_cache. I use the hook.

If you go with some automatic cleaner, I advise reviewing their configuration, sometimes they’re a bit too aggressive for my taste.


Ok thank you guys. I’ll try as soon as I get some free time. Probably only tomorrow or so. :confused:

Happy New Year for everyone :wine_glass:

Oh and thanks for the explanation. I wasn’t aware of any of that :wink::+1:


This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.