After this event I am not sure BTRFS has been a good idea anymore, I would achieve the same result with LVM except for the snapshots (althoug LVM supports them). I did it because mistakenly I was convinced about some internal command, and it doesn't matter if you are or not a power user, it still looks cumbersome the procedure rather than doing:

# zfs rollback -r /your/snapshot@date

Can I actually mount a disk while using a subvolume?

You wrote

# mount /dev/sdXY /mnt

In my case it would be /dev/sda1, did I understand properly?

Yes, that's right.

Yeah, well De{bi,vu}an is for experienced users so it doesn't need those hand-holding tools.

At least the bullseye installer now uses a @rootfs subvolume for btrfs; the old installer just used to dump the whole filesystem straight onto the root partition, which was irritating.

@OP: so boot into the snapshot from GRUB (change rootflags=subvol=@ to rootflags=subvol=btrfs/snap_20211015) but remember to either edit the / line in btrfs/snap_20211015/etc/fstab so that the subvol= bit is correct or just delete that line and set the parameters via /etc/default/grub instead.

Once booted into the snapshot mount the btrfs partition and move the snapshot:

# mount /dev/sdXY /mnt
# mv /mnt/@{,.orig}
# mv /mnt/btrfs/snap_20211015 /mnt/@

Then reboot again.

If that all works you can remove the original root subvolume:

# mount /dev/sdXY /mnt
# btrfs subvolume delete /mnt/@.orig # any nested subvolumes will have to be deleted first; rm -r might be quicker :-)

Thanks, this really clarify a lot of things however there is something that I still don't get...

Can I actually mount a disk while using a subvolume?

You wrote

# mount /dev/sdXY /mnt

In my case it would be /dev/sda1, did I understand properly?

Anyway I didn't understand many critics about BTRFS but since I am playing with FreeBSD almost daily I have started to understand the reasons, the filesystem lacks a method to restore itself, like for instance ZFS, and this procedure is a bit cumbersome. Other distros like Ubuntu, Opensuse and Arch implemented an automatic function related with the packaging upgrading to rollback.

Daedalus broke also for me on proprietary drivers. The fix is in Ceres.  Could you have  just use nouveau drivers as i did just the time the fixed version reach daedalus rather than use a full system  rollback?.

Yes I could, but later I just realized the older kernel was working, and then I understood what was the issue and simply upgraded from Ceres.

Once booted into the snapshot mount the btrfs partition and move the snapshot:

# mount /dev/sdXY /mnt
# mv /mnt/@{,.orig}
# mv /mnt/btrfs/snap_20211015 /mnt/@

Then reboot again.

If that all works you can remove the original root subvolume:

# mount /dev/sdXY /mnt
# btrfs subvolume delete /mnt/@.orig # any nested subvolumes will have to be deleted first; rm -r might be quicker :-)

FSTAB (only BTRFS Volumes)

# / was on /dev/sda1 during installation
## BTRFS SUBVOL ROOT
UUID=5a8bbd0d-e862-4e40-86f2-3f8f9b10e110 /               btrfs   subvol=@,defaults,noatime,space_cache,discard=async,autodefrag        0       0

## BTRFS SUBVOL HOME
UUID=5a8bbd0d-e862-4e40-86f2-3f8f9b10e110 /home           btrfs   subvol=@home,defaults,noatime,space_cache,discard=async,autodefrag        0       0

GRUB

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="rootflags=subvol=@ quiet"
GRUB_CMDLINE_LINUX=""

Subvolume List

ID 268 gen 382712 top level 5 path @
ID 327 gen 382712 top level 5 path @home
ID 357 gen 4558 top level 268 path btrfs/snap_20200903
ID 358 gen 4561 top level 268 path btrfs/snap_20200903ro
ID 405 gen 32786 top level 268 path btrfs/snap_20200908
ID 518 gen 365657 top level 268 path btrfs/snap_20211015

Did I miss anything?

I had some issues while updating to Daedalus with the NVIDIA Drivers and for the first time I had the necessity to rollback with BTRFS to a previous snapshot but I couldn't; I found the procedure totally counter-intuitive and I haven't still got that. Eventually I resolved my issue downloading the nvidia-driver from Ceres.

The only real and understandable answer I found is this:

https://unix.stackexchange.com/question … t-in-btrfs

However I would not be able to rollback to my previous snapshot and this made me think why, back to time, I got so crazy to install everything under BTRFS/Subvolumes if then to rollback/restore is so cumbersome...

The only point I can do is this:

sudo btrfs subvolume list /
ID 268 gen 382712 top level 5 path @
ID 327 gen 382712 top level 5 path @home
ID 357 gen 4558 top level 268 path btrfs/snap_20200903
ID 358 gen 4561 top level 268 path btrfs/snap_20200903ro
ID 405 gen 32786 top level 268 path btrfs/snap_20200908
ID 518 gen 365657 top level 268 path btrfs/snap_20211015

I thoughts that rolling-back with BTRFS was something similar to ZFS but I was totally wrong... 🤦♂️

Is anyone willing to explain to a dumb how I should have performed this rollback? 🙏