Unable to boot back into regular root after booting into a snapshot

[niveK77pur]

My Questions

I am making a discussion instead of an issue, because there is probably something wrong in my setup, and not grub-btrfs itself here (since it worked just fine on my previous Garuda installation).

Please also read the other sections, I have formulated the questions with the assumption that the rest was read.

• How to make booting into a snapshot non-persistent? So that when I reboot, I am back into my regular system, and not eternally stuck in the snapshot until I manually edit the grub.cfg?
• Is there a way for grub-btrfs to generate another snapshot which allows me to boot back into my regular system? yabsnap for example has a rollback-gen subcommand, which creates a bash script for restoring a snapshot; part of this script is to make a snapshot of the current system, in order to easily revert the snapshot. See an example script below (generated with said command).
• Does anyone happen to know what window popped up asking me to restore or not the snapshot? (IIRC the Garuda installation was using Snapper, so it might have been a snapper utility)

Thank you kindly in advance for any help, fixes, inputs or suggestions!

My Setup

I have used grub-btrfs successfully on Gardua previously, so I thought I should include it in my new ArchLinux installation as well! However, I just encountered an issue where once I booted into a snapshot, I was not able to get out of it that easily.

I make my snapshots with yabsnap instead of Snapper, because it seems like a simpler tool which does exactly what I need it to do. I am mentioning this, in case it is related to the issue.

• grub-btrfs 4.13-1
• yabsnap 2.0.6-1

What I Expected

So here is how it went previously on Garuda:

1. Boot into a snapshot via grub
2. Upon login a window pops up asking me if I want to restore my system to the snapshot, or go back to my regular system.
3. If I say yes, the snapshot will become my regular system, effectively rolling back.
4. If I say no, I can simply boot back into my regular system disregarding the snapshot (without any further intervention).

The Issue

Here is how it went on my ArchLinux installation:

1. Boot into a snapshot via grub (looked and worked same as on Garuda)
2. No window popped up (I am probably missing another tool, but I could not figure out which one)
3. Rebooting will ALWAYS put me back into the snapshot, which also happens to be a read-only filesystem.
4. I eventually realised the /boot/grub/grub.cfg was configured such as to boot with root set to the snapshot
5. grub-mkconfig ALWAYS generated a new grub.cfg for booting into the snapshot.
6. I had to manually fix the grub.cfg in order to boot back into my regular system.

Also the fact that the root filesystem was read-only prevented me from fixing things by making a # btrfs subvol snap /mnt/@ / (assuming I mount -o subvolid=5 <root partition> /mnt and my root subvolume was at @) complaining that the filesystem is read-only.

---

YabSnap rollback script

Especially note the mv @ @snapshots/rollback_20230925202616_@. I haven't really tried this script yet because I thought grub-btrfs will handle this, but I can see without a doubt how this would allow me to restore my system with much more ease.

#!/bin/bash
# Save this to a script, review and run as root to perform the rollback.

set -uexo pipefail

mkdir -p /run/mount/_yabsnap_internal_0
mount /dev/nvme0n1p3 /run/mount/_yabsnap_internal_0 -o subvolid=5

cd /run/mount/_yabsnap_internal_0

mv @ @snapshots/rollback_20230925202616_@
btrfs subvolume snapshot /.snapshots/@root-20230925125807 @

echo Please reboot to complete the rollback.
echo
echo After reboot you may delete -
echo "# sudo btrfs subvolume delete /.snapshots/rollback_20230925202616_@"

Related

Discussion #125 seems related and might have resolved my read-only filesystem issue. However, it would still not have allowed me to boot into my regular system.

Edit: fix typo

[Schievel1]

We need to sort things out here first. Grub-btrfs is not making snapshots nor does it 'restore' them. The only thing it does is generating the snapshot list in the grub menu. It does not matter what you use as an underlying tool to generate snapshots (timeshift, snapper or you can even do it manually using plain btrfs-progs) The only thing grub-btrfs needs is btrfs-progs to get a list of snapshots to work with. (Well and it needs grub obviously)

Even though most of this has not much to do with grub-btrfs I will try to answer your questions as best as I can.

• How to make booting into a snapshot non-persistent? So that when I reboot, I am back into my regular system, and not eternally stuck in the snapshot until I manually edit the grub.cfg?

I don't think persistent snapshots are what is causing this. Because your /boot is where your grub resides and /boot is usually not part of the snapshot. I rather think the tool you used for rolling back did something wrong in your grub.cfg. I have had that before with timeshift. [https://forums.gentoo.org/viewtopic-t-1144572-highlight-.html]

• Is there a way for grub-btrfs to generate another snapshot which allows me to boot back into my regular system?

No, grub-btrfs does not generate snapshots.

yabsnap for example has a rollback-gen subcommand, which creates a bash script for restoring a snapshot; part of this script is to make a snapshot of the current system, in order to easily revert the snapshot. See an example script below (generated with said command).

I havent tested this but they basically all do the same thing in one way or another. They boot you into a snapshot using the subvolid in the kernel command line, then make a snapshot from that running snapshot into @, replacing the root snapshot.

• Does anyone happen to know what window popped up asking me to restore or not the snapshot? (IIRC the Garuda installation was using Snapper, so it might have been a snapper utility)

I don't know. But it surely was not grub-btrfs. Grub-btrfs is only a bash script that hooks into grub. It does not do GUI.

[niveK77pur]

Thanks a lot for the reply and clarifications! This will hopefully help towards finding my issue. This also solves the mystery of what happened my grub.cfg, it must likely have been another tool then and not grub-btrfs (big relief)! I do recognize things in your linked forum in my situation, but I am definitely not using timeshift.

A follow up question: I understand now that grub-btrfs does nothing to/with the snapshots, nor restoring them; so as you implied there is another tool which grub-btrfs uses behind the scenes to perform the actual rollback operation. How can I determine and/or set which tool (or possibly script) grub-btrfs uses to this end? (I do not remember ever having specified anything of the sorts myself, nor could I find anything relevant in the /etc/defaut/grub-btrfs/config)

At the moment I really have no clue which tool could have caused the behavior I observed (I am fairly sure that I did not install another btrfs rollback utility besides yabsnap). As a matter of fact, I just tried my yabsnap rollback, and it also behaves differently to what I see after booting using an entry generated by grub-btrfs. For one, yabsnap does not modify the grub.cfg to boot directly into the snapshot, but it replaces the root with the snapshot (which as a result also keeps the filesystem writable, i.e. it does not go read-only).

[Schievel1]

How can I determine and/or set which tool (or possibly script) grub-btrfs uses to this end?

No, there is none. grub-btrfs reads the current snapshots on the system and write the snapshot list into the grub menu. Thats all.

Lets define the word 'restore' here. Restoring a system to an older state using btrfs-snapshots is (at least for me) when you put the old snapshot in the place of the root snapshot (the 'root snapshot' is the one that is usually booted by default by grub and usually is called @ or @/. This is the one you would call main or master but for btrfs it isn't different from any other snapshot).
Restoring is a thing that is very easy to achieve with btrfs: move the old snapshot in the place of the root snapshot. Literally moving using mv will do that, and all those tools, be it timeshift, snapper or yabsnap will do a simple mv or cp from the snapshot to @ in one way or another. grub-btrfs does not do that, nor does it invoke any other tool to do that.

What grub-btrfs does is providing a list of snapshots in your grub menu. Grub can boot the kernel using the snapshots by passing that to the kernel. It will then boot into that snapshot and your system will have the state from the time the snapshot was taken. But next time you boot again and you boot the default entry it will boot you back into the root snapshot @, not the snapshot you took earlier. grub-btrfs did not change anything on disk then.

(I do not remember ever having specified anything of the sorts myself, nor could I find anything relevant in the /etc/defaut/grub-btrfs/config)

Yes, thats because there is nothing to find. Grub-btrfs does not invoke a different tool.

At the moment I really have no clue which tool could have caused the behavior I observed (I am fairly sure that I did not install another btrfs rollback utility besides yabsnap). As a matter of fact, I just tried my yabsnap rollback, and it also behaves differently to what I see after booting using an entry generated by grub-btrfs. For one, yabsnap does not modify the grub.cfg to boot directly into the snapshot, but it replaces the root with the snapshot (which as a result also keeps the filesystem writable, i.e. it does not go read-only).

I have an idea. I can not remember what I did when I wrote that forum thread, it's to long ago. So maybe you want to try yourself.
When you boot into a snapshot using grub-btrfs you pass subvol=pathtothesnapshot to the kernel. The kernel then boots into said snapshot. (you don't need to do that manually, that is what grub-btrfs does for you when selecting a snapshot from the list in the grub-menu)
When you booted and then invoke grub-mkconfig I have the suspicion grub will detect the snapshot you booted, assume its the root-snapshot and write that into the default boot entry.
So, do you remember if you invoked grub-mkconfig while booted into the snapshot?

[niveK77pur]

Thanks again for the clarifications and patience! I had indeed run grub-mkconfigwhile booted into a snapshot. I must have gotten confused and disoriented at some point, which lead me to make things worse than they really were. I can now confirm that booting into a snapshot, and then booting regularly puts me back to where I was before I booted into the snapshot!

And to confirm your suspicion in the last point, I also ran grub-mkconfig -o /tmp/grub.cfg while booted into a snapshot to check the value of subvol, and indeed it was set to the snapshot! This effectively had me eternally trapped within a snapshot. So as expected, none other than I was the culprit :)

My initial question and issue has been answered and clarified, thank you very much again for all the information; I understand now much better what exactly is going on!

---

I also created a VM with GarudaOS inside just to check how they might have done it, especially now that I understand better which role grub-btrfs plays. And it appears to be something related to snapper.

This of course goes beyond the scope of this issue and project, I just thought I would share it to draw a more complete picture! (Unless of course there is a more specific interplay between snapper and grub-btrfs, but from my understanding now, it will probably be on the snapper side)