This usually happens when you create a manual subvolume and mount it at /.snapshots. I would strongly advise you not to do that unless you have a specific reason to do this. Snapper will create this subvolume itself when you create the config so if it already exists it will fail.
This creates a snapshot at /.snapshots. You are probably trying to put a snapshot inside that. It should be something like:
If you are going to us Snapper, I recommend not doing this at all. Just let Snapper deal with it. It handles everything automatically.
Yes.
The problem is that Snapper tries to create a subvolume at that location but it cannot since you already created a directory and mounted a subvolume on it.
If you delete your subvolume and remove the directory, the Snapper command will work fine.
ID 256 gen 2508 top level 5 path @
ID 257 gen 2509 top level 5 path @home
ID 258 gen 2508 top level 5 path @log
ID 259 gen 2477 top level 5 path @pkg
ID 260 gen 1804 top level 5 path @.snapshots
ID 261 gen 18 top level 256 path var/lib/portables
ID 262 gen 18 top level 256 path var/lib/machines
I got now. I noticed that after running Snapper configuration it created automatically a /.snapshots folder. So it’s the way it works and one of the reasons the previous problem.
Everything seems to be working fine now. In your opinion, is it really better to go with Snapper instead btrfs command?
The reason I am asking this is because now I notice somethings “strange”, Or perhaps the problem is with me.
For example, running sudo btrfs subvolume list / I receive the below output:
ID 256 gen 2631 top level 5 path @
ID 257 gen 2632 top level 5 path @home
ID 258 gen 2632 top level 5 path @log
ID 259 gen 2627 top level 5 path @pkg
ID 260 gen 1804 top level 5 path @.snapshots
ID 261 gen 18 top level 256 path var/lib/portables
ID 262 gen 18 top level 256 path var/lib/machines
ID 263 gen 2625 top level 256 path .snapshots
ID 264 gen 2622 top level 263 path .snapshots/1/snapshot
The two last lines refers to the snapshot I ran now. But that 5th line is referring to that older /.snapshots folder, which I have already deleted, through rmdir (I have also commented the related line at /etc/fstab. Do you think that even so everything is Ok?
I can’t “list” snapshots through sudo snapper list, because it returns the below error, saying that “root configuration” does not exists and that probably Snapper is not configured:
A configuração "root" não existe. Provavelmente, o snapper não está configurado.
Consulte "man snapper" para obter mais instruções.
Well, is the size really that small? A / snapshot with just 8 GB?
Once again, many thanks for your support, and sorry for so many questions.
The advantage of using Snapper is that can handle taking regular snapshots and also automatically pruning them based on retention rules. There are also other tools that know how to work with Snapper snapshots.
You deleted the folder but the subvolume is still there because it is a level above /. You can either mount the root of the partition and delete it or just ignore it. It won’t hurt anything.
ncdu can’t tell you how much space a snapshot is taking up.
Snapshots track the state of the data. A recent snapshot will take very little space. Snapshots only use space for data they track exclusively plus a small amount of metadata overhead.
In simpler terms if you have only a single snapshot, the space used is roughly equal to the amount of data that has changed since you took the snapshot.
@Reiner_Sanders ,
A last minute remark: I followed this and it works.
I don’t want to open a new case. As far I understand GRUB needs /boot/grub/grubenv to be on a non BTRFS partition. So I manually selected an ext4 /boot partition.
The only ‘problem’ is GRUB_SAVEDEFAULT does not work for me. But the working GRUB snapshot selection counterbalances it.
