Help me remove my old snapperd snapshots after upgrading fedora through installer

Ask Fedora
1

I am a btrfs novice and I have gotten myself kind of confused on my fedora laptop.

I previously used snapperd to take snapshots when using dnf. I took a snapshot before attempting to upgrade to fedora 41 from fedora 40. The upgrade failed and I used snapperd to rollback to that snapshot.

Later I used an installer usb stick and installed fedora 41 to a new subvolume that I named @root and mounted my old @home subvolume on /home. I had some other weird issues in the meantime like not being able to boot fedora 40 kernels with the exception of the one I had running during the snapshot, and dracut holding onto the fedora 41 kernels I had installed during the upgrade.

Now the problem is I still have a bunch of old snapshots lying around in my btrfs volume. When I try to run btrfs subvolume delete /.snapshots/309/snapshot I get “No such file or directory”. I did note in my troubleshooting that there is a /home/.snapshots but it is empty

# btrfs subvolume list /
ID 256 gen 522448 top level 5 path var/lib/machines
ID 259 gen 554373 top level 5 path @home
ID 260 gen 522481 top level 5 path .snapshots
ID 261 gen 522124 top level 259 path @home/.snapshots
ID 570 gen 522480 top level 260 path .snapshots/309/snapshot
ID 571 gen 522061 top level 260 path .snapshots/310/snapshot
ID 572 gen 522085 top level 260 path .snapshots/311/snapshot
ID 573 gen 522087 top level 260 path .snapshots/312/snapshot
ID 574 gen 522192 top level 260 path .snapshots/313/snapshot
ID 575 gen 522480 top level 260 path .snapshots/314/snapshot
ID 576 gen 552382 top level 260 path .snapshots/315/snapshot
ID 577 gen 554372 top level 5 path @root
ID 578 gen 554012 top level 577 path var/lib/machines

You can also see that my default subvolume is one of the snapshots that I rolled back to after the failed upgrade. That seems bad but I’m not sure if that affects anything.

# btrfs subvolume get-default  /
ID 576 gen 552382 top level 260 path .snapshots/315/snapshot

My fstab looks like this.

# cat /etc/fstab
....
UUID=bd685ed9-4b31-49f5-87d2-11986a865274 /                       btrfs   subvol=@root,compress=zstd:1 0 0
UUID=C893-E8D3          /boot/efi               vfat    umask=0077,shortname=winnt 0 2
UUID=bd685ed9-4b31-49f5-87d2-11986a865274 /home                   btrfs   subvol=@home    0 0
....

Any pointers would be appreciated,
Jordan.

2

The .snapshots subvolume is located at the top-level of the file system. That location isn’t available through any mounted search path, that’s why the command to delete doesn’t work.

Option A:

# mount -o subvolid=5 --uuid bd685ed9-4b31-49f5-87d2-11986a865274 /mnt
# btrfs subvolume delete /mnt/.snapshots/309/snapshot

Option B:

You can also delete a subvolume by ID, found in the 2nd column of the subvolume list results, without first mounting the top level of the file system.

# btrfs subvolume delete --subvolid 570 /

Due to the clean install, your kernel command line has a rootflags=subvol command that will override the default subvolume set on the file system. So it doesn’t matter. But if you want to clean this up back to default you can use:

# btrfs subvolume set-default 5 /

It’s esoteric trivia, but every b-tree on Btrfs has an ID. ID 5 is the default file b-tree, the subvolume created at mkfs time. This subvolume can’t be deleted, and has no name, so we just call it “the top-level of the file system”.

During early development some folks asked (more or less, I’m paraphrasing) “uhh 5? how am I going to ever remember that?”. So the developers added an alias, ID 0, mapped to ID 5. So you could also use 0 instead of 5 in the above commands. It’s the same.

1 Like
3

If you prefer a GUI, the Storage section of Cockpit makes seeing and removing btrfs snapshots very easy.

1 Like
4

Thank you that seems to have worked. I’ve deleted all but the snapshot
that saved me and after I reboot again I’ll delete that as well.

I also appreciate the esoteric trivia. I like that computer people still
cannot count.

1 Like