You are not logged in.
Pages: 1
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)
Offline
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.
To obtain a root shell use su -. Using just su will result in "command not found" messages.
Offline
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)
Offline
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?.
Offline
@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 :-)
To obtain a root shell use su -. Using just su will result in "command not found" messages.
Offline
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.
Offline
@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)
Offline
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.
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.
To obtain a root shell use su -. Using just su will result in "command not found" messages.
Offline
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
Offline
Pages: 1