How do I use Timeshift/btrfs to permanently restore to a previous snapshot?

[Molski]

This is where the other post led me to. And just basically having to rename what the default menuentry> linux, linuxrd is booting from?

Which I think requires me live booting to do?

[Molski]

@Zesko

what is the version of grub-btrfs?

pacman -Qi grub-btrfs
Name            : grub-btrfs
Version         : 4.11-2
...

[Zesko]

Do not need to use live booting.
There is a trick to fix grub boot config directly.

Change

@Molski

menuentry 'Manjaro Linux' --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-4dd57ba2-0498-494e-aa48-191b52801fcf' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_gpt
        insmod btrfs
        search --no-floppy --fs-uuid --set=root 4dd57ba2-0498-494e-aa48-191b52801fcf
        linux   /timeshift-btrfs/snapshots/2022-10-15_23-44-29/@/boot/vmlinuz-5.15-x86_64 root=UUID=4dd57ba2-0498-494e-aa48-191b52801fcf rw rootflags=subvol=timeshift-btrfs/snapshots/2022-10-15_23-44-29/@  apparmor=1 security=apparmor resume=UUID=9f5a3a86-21ad-4bcc-9db7-2377aee3d05c udev.log_priority=3 amd_iommu=on vfio-pci.ids=10de:2216,10de:1aef video=efifb:off
        initrd  /timeshift-btrfs/snapshots/2022-10-15_23-44-29/@/boot/amd-ucode.img /timeshift-btrfs/snapshots/2022-10-15_23-44-29/@/boot/initramfs-5.15-x86_64.img
}

to

menuentry 'Manjaro Linux' --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-4dd57ba2-0498-494e-aa48-191b52801fcf' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_gpt
        insmod btrfs
        search --no-floppy --fs-uuid --set=root 4dd57ba2-0498-494e-aa48-191b52801fcf
        linux   /@/boot/vmlinuz-5.15-x86_64 root=UUID=4dd57ba2-0498-494e-aa48-191b52801fcf rw rootflags=subvol=@  apparmor=1 security=apparmor resume=UUID=9f5a3a86-21ad-4bcc-9db7-2377aee3d05c udev.log_priority=3 amd_iommu=on vfio-pci.ids=10de:2216,10de:1aef video=efifb:off
        initrd  /@/boot/amd-ucode.img /@/boot/initramfs-5.15-x86_64.img
}

then reboot, if it works

[Molski]

We’ve been replying very fast back and forth, thank you for this.

Let me digest this before I do this. I need a fall back, in case I make this worse.

Oh I do have my other boot options for fall back. But won’t this get over written when I run grub-mkconfig?

[Zesko]

1. Fix this grub boot config. Please not use grub-mkconfig or update-grub
2. Then reboot
3. Check if it has the issue.
4. If no issue, then run update-grub or grub-mkconfig to overwrite this grub boot config.
5. Check if this Grub boot config is correct.

[andreas85]

You may find some ideas from searching for btrfs rollback in the forum:

[how to] Manual rollback with btrfs

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 nece…

Btrfs Snapper, the Suse way with rollback

Hello, I’ve tried to install Arch or Manjaro with or without the Architect Installer, which supports Snapper rollback and bootable snapshots though the default subvolume like Suse worked out. I wanted to provide this partition sheme also for unexpirienced users so i modified Manjaro Architect so everyone can easily install. I created a PKGBUILD for Grub with the patches from Suse, also I habe modified snap-pac-grub so the snapshots occur on grub because i dont use grub-btrfs because with the Su…

[how to] rescue data from a damaged btrfs volume

Difficulty: ★★☆☆☆ You used btrfs. Now it’s paying off. There is an easy way out (I’ve already done this myself):

In most cases, when a btrfs volume breaks, it is possible to recover the data

This is because btrfs works with copy on write. This means that new changes are always appended at the end, so to speak. The previously existing data is not actually overwritten. (In reality this is a bit more complicated, but for us here this simplified view is sufficient). If the file system ge…

…

And you find good Information about Btrfs in the wiki

Btrfs

[Zesko]

This issue has nothing to do with restoring btrfs snapshot, but GRUB boot configuration is wrong because running update-grub or grub-mkconfig incorrectly overwrites the GRUB boot config when running your system in the writable snapshot and ignoring the hints of Timeshift “Please restore the snapshot”.

[Molski]

@Zesko

1. Fix this grub boot config. Please not use grub-mkconfig or update-grub
2. Then reboot
3. Check if it has the issue.
4. If no issue, then run update-grub or grub-mkconfig to overwrite this grub boot config.
5. Check if this Grub boot config is correct.

Edited, rebooted, still have the warning.

I modified these 4 lines:

        #linux  /timeshift-btrfs/snapshots/2022-10-15_23-44-29/@/boot/vmlinuz-5.15-x86_64 root=UUID=4dd57ba2-0498-494e-aa48-191b52801fcf rw rootflags=subvol=timeshift-btrfs/snapshots/2022-10-15_23-44-29/@  apparmor=1 security=apparmor resume=UUID=9f5a3a
86-21ad-4bcc-9db7-2377aee3d05c udev.log_priority=3 amd_iommu=on vfio-pci.ids=10de:2216,10de:1aef video=efifb:off
        linux   /@/boot/vmlinuz-5.15-x86_64 root=UUID=4dd57ba2-0498-494e-aa48-191b52801fcf rw rootflags=subvol=@  apparmor=1 security=apparmor resume=UUID=9f5a3a86-21ad-4bcc-9db7-2377aee3d05c udev.log_priority=3 amd_iommu=on vfio-pci.ids=10de:2216,10de:
1aef video=efifb:off
        #initrd /timeshift-btrfs/snapshots/2022-10-15_23-44-29/@/boot/amd-ucode.img /timeshift-btrfs/snapshots/2022-10-15_23-44-29/@/boot/initramfs-5.15-x86_64.img
        initrd  /@/boot/amd-ucode.img /@/boot/initramfs-5.15-x86_64.img

[Zesko]

In the grub boot menu, did you select the first boot entry “Manjaro Linux”? Or fallback?

[Molski]

The first one. Which is the one I modified.

Edit: I will double check, and reboot again. But I’m 99.9% sure I did that part right.

I edited the default/first entry. Rebooting now.

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Manjaro Linux' --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-4dd57ba2-0498-494e-aa48-191b52801fcf' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_gpt
        insmod btrfs
        search --no-floppy --fs-uuid --set=root 4dd57ba2-0498-494e-aa48-191b52801fcf
        #linux  /timeshift-btrfs/snapshots/2022-10-15_23-44-29/@/boot/vmlinuz-5.15-x86_64 root=UUID=4dd57ba2-0498-494e-aa48-191b52801fcf rw rootflags=subvol=timeshift-btrfs/snapshots/2022-10-15_23-44-29/@  apparmor=1 security=apparmor resume=UUID=9f5a3a
86-21ad-4bcc-9db7-2377aee3d05c udev.log_priority=3 amd_iommu=on vfio-pci.ids=10de:2216,10de:1aef video=efifb:off
        linux   /@/boot/vmlinuz-5.15-x86_64 root=UUID=4dd57ba2-0498-494e-aa48-191b52801fcf rw rootflags=subvol=@  apparmor=1 security=apparmor resume=UUID=9f5a3a86-21ad-4bcc-9db7-2377aee3d05c udev.log_priority=3 amd_iommu=on vfio-pci.ids=10de:2216,10de:
1aef video=efifb:off
        #initrd /timeshift-btrfs/snapshots/2022-10-15_23-44-29/@/boot/amd-ucode.img /timeshift-btrfs/snapshots/2022-10-15_23-44-29/@/boot/initramfs-5.15-x86_64.img
        initrd  /@/boot/amd-ucode.img /@/boot/initramfs-5.15-x86_64.img
}

[Molski]

Yeah, same warning. I actually thought this would work too!

[Zesko]

If that does not work, then use manjaro-chroot on Live USB to fix Grub.

# mount -t btrfs /dev/nvme0n1p2 /mnt
# manjaro-chroot /mnt/@
# mount /boot/efi
# update-grub

Then check what is the output cat /boot/grub/grub.cfg

[Molski]

If my plan is to rip out Timeshift and replace it with Snapper. My volumes are just fine, correct? I guess that warning doesn’t even matter then. Since I’ll be removing Timeshift.

But I do want to be booting from /@/… So how do I make the grub.cfg entries permanent? This is something I can’t change from /etc/default/grub.

Edit: Let me guess, I do what you just said in the previous post.

[Zesko]

@Molski

My volumes are just fine, correct? I guess that warning doesn’t even matter then. Since I’ll be removing Timeshift.

Yes, your volumes are fine, but your system is still running in the Timeshift writable snapshot, not in the root subvolume @.

The important point is you should only fix Grub problem, not Timeshift problem.
After the fix from Grub, then you can decide later if you want to switch timeshift to snapper.

[Zesko]

I noticed that you edited /boot/grub/grub.cfg but it was in the writable snapshot, not in your root subvolume.
That is why Grub does not read this edited Grub config from the snapshot at boot, but it reads the other incorrect Grub config in the root subvolume @ .

Maybe solution:

You should fix the other Grub config right in the root subvolume @, not snapshot.

If you do not want to use chroot on Live USB,

1. mount your root subvolume and browse it.

$ su
# mount -t btrfs -o subvol=/ /dev/nvme0n1p2 /mnt
# cd /mnt
# cat @/boot/grub/grub.cfg

2. You can check if @/boot/grub/grub.cfg is wrong, then you can fix it.
3. Then reboot.
4. If it works, you should run update-grub or grub-mkconfig.
5. Check if /boot/grub/grub.cfg is correct.

Or the other solution is also possible:

How do I use Timeshift/btrfs to permanently restore to a previous snapshot?

If that does not work, then use manjaro-chroot on Live USB to fix Grub. # mount -t btrfs /dev/nvme0n1p2 /mnt # manjaro-chroot /mnt/@ # mount /boot/efi # update-grub Then check what is the output cat /boot/grub/grub.cfg

[Molski]

I actually started a new download of a Manjaro live image (since I’ve had dozens of kernel updates, and probably many btrfs-tools updates since the one I had on a flash drive sitting around for who knows how long). And I had to head out of the house for a while anyway.

When I got back, mounting the root subvolume worked, and fixed grub! So I didn’t even need to boot the image I downloaded.

One problem, it undid the whole reason I needed to restore a previous snapshot. An update broke my networking to all of my VMs, and I needed them to do my work. So I had to restore to undo the update, then worry about troubleshooting the problem with the update later.

grep 'upgraded.*linux515' pacman.log | tail -5
[2022-09-13T02:48:09-0600] [ALPM] upgraded linux515 (5.15.60-1 -> 5.15.65-1)
[2022-10-06T20:13:03-0600] [ALPM] upgraded linux515 (5.15.65-1 -> 5.15.71-1)
[2022-10-10T21:22:02-0600] [ALPM] upgraded linux515 (5.15.71-1 -> 5.15.72-1)
[2022-10-15T23:44:32-0600] [ALPM] upgraded linux515 (5.15.72-1 -> 5.15.74-3)
[2022-10-18T16:59:21-0600] [ALPM] upgraded linux515 (5.15.72-1 -> 5.15.74-3)

I restored the image back to the 2022-10-15 snapshot because I think the kernel upgrade to 5.15.74-3 (which was only part of that update) on 2022-10-18 caused my initial issue. This is what made me restore in the first place. I’m only guessing at that, I just needed a quick way to undo that update, so I used the Timeshift restore feature. (But at least I was able to get my work done, while working on the older RW 2022-10-15 snapshot. Since the VMs I work in, aren’t affected by these snapshots.)

So basically I’m back to square one. Grub is fixed, but I am running the snapshot which made me need to restore in the first place.

I least I can try to downgrade the packages that were upgraded from here I guess? And I did learn a lot thanks to you @Zesko. I really appreciate it.

I am still really confused why Timeshift operates this way. By using the restore feature, I was temporarily able to work on the snapshot I wanted to. But I had to undo the entire restore to fix how it did the restore.

I am dead tired, and going delirious. I need to get some sleep and come back to this fresh. But thank you so much for all your help @Zesko.

[Zesko]

1. Fix Grub boot config in the current writable snapshot " 2022-10-15" .

$ su
# mount -t btrfs -o subvol=/ /dev/nvme0n1p2 /mnt
# cd /mnt
# cat timeshift-btrfs/snapshots/2022-10-15_23-44-29/@/boot/grub/grub.cfg

Check if this file “gub.cfg” is correct and boots into the subvolume @
You can fix it carefully what you know.

2. Restore or replace this good snapshot with the old broken root-subvolume @ after fixing the Grub config.

# cd /mnt
# mv  @ @broken
# btrfs subvolume snapshot timeshift-btrfs/snapshots/2022-10-15_23-44-29/@ @

3. Then reboot into the normal system " 2022-10-15"

4. Run sudo update-grub. Then check if the grub.cfg is correct.

5. You can delete some wrong snapshots (inclusive the wrong grub.cfg) and the broken subvolume @broken

6. Done.

[Molski]

Ahhh! Of course! I actually even did that. I was just going by an excluded snapshot directory thinking I was on the newest snapshot. I had to go to sleep, I didn’t even test my VMs.

It makes so much more sense when you don’t go 24+ hours awake, going off only a 2 hour sleep prior to that.

Thanks so much @Zesko, you’re a lifesaver. And all the effort with all those posts you put in, I really appreciate it!

Now that I understand so much more about brtfs (and Timeshift), I think this should really be considered a bug in Timeshift. Or at the very least, not following best practices for using btrfs.

[Zesko]

The most important thing is you shouldn’t ignore Timeshift’s hints “Please restore snapshot” in the future.

After booting into the writable snapshot, you have to restore your selected good snapshot in Timeshift immediately, then reboot immediately without changing any data in this snapshot.

In general, Timeshift snapshot is writable but has no protection against any modification, for example:
You got this issue because the grub-update or grub-mkconfig incorrectly overwrote the good version of the grub configuration in the snapshot, then you always booted into the snapshot.

[Molski]

@Zesko

The most important thing is you shouldn’t ignore Timeshift’s hints “Please restore snapshot” in the future.

Oh I completely get it, NOW anyway. My sleep deprivation and work wasn’t helping me deal with this. But anyone that is very familiar with Linux, but not Timeshift and btrfs (like me) would not get this, at first anyway.

That “Restore” button does NOT do what you would expect it would. Even with me dealing with ZFS for 25ish years, and other snapshoting filesystems, NetApp and other enterprise HD arrays, etc etc.