Difficulty: ★★☆☆☆ 
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 drivesbtrfs-progs: For creating and listing snapshotsmc: To control what is happening on the volume
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
[details=“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
[/details]
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 
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
- i did roll back successfully
- i only could rescue my data
- i gave up
- I’m in the middle of it