[SOLVED] BTRFS Drama

Danielsan · 2021-10-16 08:30:37

Hi Guys,

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? 🙏

Last edited by Danielsan (2021-10-16 08:31:25)

Head_on_a_Stick · 2021-10-16 10:19:55

It's a bit tricky to help without knowing your backup and restore method but for my system I would just boot into the snapshot subvolume and rename (mv) it to the top level subvolume. I don't have a / line in /etc/fstab but if you do then I think that would have to be changed to boot into the subvolume without errors (which is why I don't have that line in my file) but otherwise it's pretty simple.

Danielsan · 2021-10-16 15:49:00

Yes sure thing! Thanks!

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?

Last edited by Danielsan (2021-10-16 16:46:19)

thierrybo · 2021-10-17 07:10:19

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?.

Head_on_a_Stick · 2021-10-17 09:23:34

@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 :-)

Danielsan · 2021-10-17 15:28:55

thierrybo wrote:

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.

Danielsan · 2021-10-17 16:06:38

Head_on_a_Stick wrote:

@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.

Last edited by Danielsan (2021-10-17 16:09:26)

Head_on_a_Stick · 2021-10-17 17:00:25

Danielsan wrote:

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.

Danielsan wrote:

Other distros like Ubuntu, Opensuse and Arch implemented an automatic function related with the packaging upgrading to rollback

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.

Danielsan · 2021-10-19 15:01:53

Thank you very much again... 🍺

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

The officially official Devuan Forum!

#1 2021-10-16 08:30:37

[SOLVED] BTRFS Drama

#2 2021-10-16 10:19:55

Re: [SOLVED] BTRFS Drama

#3 2021-10-16 15:49:00

Re: [SOLVED] BTRFS Drama

#4 2021-10-17 07:10:19

Re: [SOLVED] BTRFS Drama

#5 2021-10-17 09:23:34

Re: [SOLVED] BTRFS Drama

#6 2021-10-17 15:28:55

Re: [SOLVED] BTRFS Drama

#7 2021-10-17 16:06:38

Re: [SOLVED] BTRFS Drama

#8 2021-10-17 17:00:25

Re: [SOLVED] BTRFS Drama

#9 2021-10-19 15:01:53

Re: [SOLVED] BTRFS Drama

Board footer