[how to] Manual rollback with btrfs

Difficulty: ★★☆☆☆ :de: :uk:

Why roll back?
  • If Manjaro doesn’t want to boot into the graphical user interface.
  • If an update managed to break an application you need

Now btrfs pays off! With a good layout and snapper. Please read all of the instructions through to the end before you begin.
Only a few steps are necessary for a rollback:

Boot a rescue Manjaro

Either from CD or from a live USB stick or somewhere else. Under no circumstances use the btrfs volume that you want to repair. If the necessary programs are not there, install with:

pamac install btrfs-progs mc gparted
  • gparted: To get an overview of the device names of the drives
  • btrfs-progs: For creating and listing snapshots
  • mc: To control what is happening on the volume

:warning: The following is not a playground for experimentation.
All the following commands require you to be root, and not without reason. Please remember to check each command 3 times for typing errors. It’s all very easy. But it intervenes deeply in the system. No fear. Errors can be repaired. But that costs time and nerves unnecessarily.

So open 2 (!) terminals and become root in each one

sudo su
Where is the "good" snapshot?

First look at the disks with gparted and search for the device with the btrfs file system that should get the rollback. Then mount this volume in the 1st terminal:

mkdir /mnt/ROOT; cd /mnt/ROOT

My btrfs volume is /dev/nvme0n1p3 Please insert your device in the following command!

mount -t btrfs -o subvol=/ /dev/nvme0n1p3/ mnt/ROOT

From now on you can start mc in the 2nd terminal and see everything we do. The layout of the btrfs volume can also be seen there.

cd /mnt/ROOT; mc

In my layout, the system is at @ and the snapshots are under @snapshots. We are looking for the snapshot whose timestamp is so that the system was still OK at this point in time. Don’t worry, the data afterwards won’t be lost. For me this seems to be @snapshots/18330/snapshot

Save the broken system state

My booting system is under @ , and my snapshots are under @snapshots. The @ is broken and must be cleared away. (rw-snapshots can be moved, and @ is an rw-snapshot) I switch in mc into the right window with TAB then into “directory” @snapshots , then TAB in the left window with F6 move the “@” and rename it to “kaputt1” . Or do this in the 1st terminal:

mv /mnt/ROOT/@ /mnt/ROOT/@snapshots/kaputt1

mc is a great way to control how this works.

Prepare the selected snapshot for booting

The system needs an rw snapshot to boot. But the snapshots that snapper takes are read-only for a reason. So we have to create a new rw-snapshot from the existing snapshot.

btrfs subvolume snapshot /mnt/ROOT/@snapshots/18330/snapshot /mnt/ROOT/@

We now make this snapshot the default

btrfs subvolume set-default @

Check again with mc! Then quit mc.

umount /mnt/ROOT

DONE

If you have selected the good snapshot the system will boot. I had to repeat the whole thing again with snapshot 18347 :wink:

clean up

A few days after the rollback you have to remove the now unnecessary snapshot with the broken file system. It’s called @ snapshots / kaputt1 This can be done from within the running system. (btrfs is great)

These instructions assume that the directory (/ boot) with the kernel (which can be changed during the update) is on the btrfs volume. This ensures that matching kernels, initramfs and modules are available for each snapshot. With a disconnected /boot drive (as was the case in the past), rolling back can be extremely difficult.

When this fails, follow this link to rescue your data

How did it go
  • i did roll back successfully
  • i only could rescue my data
  • i gave up
  • I’m in the middle of it

0 voters

3 Likes
  • All snapshots suddenly disappeared in timeshift (Bug) after the bad corruption data.
  • grub-btrfs could restore only the subvolume root @/, but not @home/.

I just had to manually restore my @home subvolume and followed similar your instructions. It seems the success without any problem. Thanks!

But I did not run btrfs subvolume set-default @home. Do I need it?

There are 4 subvolumes @cache/, @log/, @home/ and @/, they were defined by Manjaro default.

❯ sudo btrfs subvolume list /
ID 258 gen 147588 top level 5 path @cache
ID 259 gen 147630 top level 5 path @log
ID 1471 gen 147563 top level 5 path @snapshots/home_kaputt1
ID 1842 gen 147586 top level 5 path @
ID 1843 gen 147485 top level 5 path timeshift-btrfs/snapshots/2022-01-25_20-50-54/@
ID 1844 gen 147564 top level 5 path timeshift-btrfs/snapshots/2022-01-25_20-50-54/@home
ID 1877 gen 147631 top level 5 path timeshift-btrfs/snapshots/2022-01-30_13-16-57/@
ID 1878 gen 147567 top level 5 path timeshift-btrfs/snapshots/2022-01-30_13-16-57/@home
ID 1881 gen 147631 top level 5 path @home
1 Like

No, this is only needed for subvolume @, so this gets the default subvolume when mounting without specifying any subvolume

You may also have a look at:

Btrfs - Wiki

https://wiki.manjaro.org/index.php/Btrfs

6 posts were split to a new topic: How to restore snapshot using the default layout of snapper

FastTrack (for experienced as root)

:warning: You may need to adapt ALL commands to your Btrfs layout

1) Mount BTRFS volume

create /mnt/ROOT if missing, then

mount /dev/sdy1 /mnt/ROOT
2) Save current state (optional)
mv /mnt/ROOT/@ /mnt/ROOT/@snapshots/broken_220628...

3) Restore snapshot 318

btrfs subvolume snapshot /mnt/ROOT/@snapshots/318/snapshot /mnt/ROOT/@ 

4) Declare as default (to boot)

btrfs subvolume set-default /mnt/ROOT/@

boot (for the brave)

reboot
5) cleanup (optional later)
btrfs subvolume delete /.snapshots/broken_220628...

This did work via ssh in a running system while @ was mounted as filesystem-root (/) without live-manjaro
:smiling_face_with_three_hearts:

This may be the same as:

snapper --print-number rollback 318