Timeshift and grub-btrfs

There is not a lot of info in the man for grub-btrfs regarding what to expect.
I just wanted to follow up on something written a few days ago that iv only just got to reading and digesting.
So what exactly happens when you boot from the grub-btrfs created entries? I assume its not like a system restore, it does not replace your /@ with the chosen snapshot. Im guessing it just boots to that snapshot and …? maybe you are supposed to replace your old /@ with whatever snapshot you want and then reboot again (not forgetting to change the boot option back to a normal boot, (if it boots the last option by default)). And you can do that restore/replacement of /@ with a timeshift restore?

What should i be expecting and what should i avoid doing?

I followed a guide written by on our members to get this right. I found out the hard way that if you don’t do what’s suggested there after restoring a snapshot, things eventually go south.

1 Like


So i have been tinkering for over a week with all this stuff (what a headache i have), however, there is a good chance i have used the restore button on timeshift and i might have tried the grub but i think i just looked at the menu and didn’t actually use it, but not 100% sure.

How do i check to be sure that im not sitting on a timebomb ?

rootflags=subvol=timeshift-btrfs/.../@ and change it to rootflags=subvol=@
I dont see anything that looks like that in /etc/default/grub is that where i should even be looking?

i seem to be booting off the correct snapshot.

❱cat /etc/fstab | grep btrfs
UUID=5bf86f84-a752-4841-bcba-21f873673765 /              btrfs   subvol=/@,defaults,noatime,discard=async,ssd 0 0
UUID=5bf86f84-a752-4841-bcba-21f873673765 /home          btrfs   subvol=/@home,defaults,noatime,discard=async,ssd 0 0
UUID=5bf86f84-a752-4841-bcba-21f873673765 /var/cache     btrfs   subvol=/@cache,defaults,noatime,discard=async,ssd 0 0
UUID=5bf86f84-a752-4841-bcba-21f873673765 /var/log       btrfs   subvol=/@log,defaults,noatime,discard=async,ssd 0 0

I have done many update-grubs since then though.

but who knows my head is spinning enough just from trying to figure a way to sync my timeshift snapshots over to an external btrfs drive, add them and delete them (but thats another story).

So did it get “fixed”?

It sounds like the post above was talking about the restore button on timeshift. Does the same apply to the grub menu restore as well? if not how do they differ?

I’ve done it dozens of times since flawlessly. Virtualized, on my main workstation, and laptops. I’ve tried to find this bug countless times, the report and/or fix. The Timeshift Github only has 49 closed issues, none seem to contain it, but I did not click into every one of them. When I used it before, it also changed the top level ID of the snapshot restored, which should be 5. As well as really screwing up my /boot/grub/grub.cfg every time I tried to generate it.

While booting into Timeshift snpshots using grub-btrfs, it looks fine. The first thing you may notice is all your volume mounts don’t have the option of subvol=@, subvol=@home, etc. They are all: subvol=/timeshift-btrfs/snapshots/2024-06-21-_00-00-00/@ or the like. You can see this using the mount command (or findmnt /). This annoys me, but it works, so what’s the problem?

Snapshots are often rollback points. If you boot into a read write snapshot, this rollback point (which may of been taken right before an update) is now your live root volume. Not a point you would normally want to rollback to.

But even worse, each of these snapshots (which are also subvolumes) also has a parent UUID. When you start booting into these read/write snapshots and doing it multiple times. You create these trees of snapshots, which would be hell to manage tracking down which snapshots belongs to what parents.

Again, this is why most people use a third party app to manage snapshots to that level.

But I’ve booted into snapshots this way for checking something, or just playing around. But I render that snapshot useless for all other purposes, and usually delete it after. And then I backup my (read only) snapshots.

well i am just more and more confused then.

I do not have any mention of rootflags in my /etc/default/grub but my system does boot with that option

❱cat /proc/cmdline
BOOT_IMAGE=/@/boot/vmlinuz-6.9-x86_64 root=UUID=5bf86f84-a752-4841-bcba-21f873673765 rw rootflags=subvol=@ quiet splash udev.log_priority=3

So something is doing something. I definitely have used the restore on timeshift now I think about it, so has TimeShift been fixed/updated to adjust the grub from somewhere else and then put it back to what it should be after a restore properly? maybe there was never a problem and it was just this chaps system?

If i added rootflags=subvol=@ in my /etc/default/grub it would most likely cause a problem when timeshift tries to restore because it wont be able to boot from another source?? (maybe^^). I should leave it alone?
So is my system going to be ok, how do i know, it looks ok to me?

Im still wondering how a grub menu restore goes? Is it any different, what should i expect?

This is what im trying to do, use timeshift but people are like “ooo, you need to be carful there, dont restore and then keep using it or dont forget to do XYZ or there will be real problems” so i dunno :frowning:

Restore all you want. I am only talking about if you use the GRUB boot menu to boot into a read/write snapshot that Timeshift creates, then restore. Again, nothing to do with Timeshift.

Well it used to not work properly, at least for me, and apparently others. But we’ve been over this before, right?

I don’t have anything tied to a subvolume in my /etc/default/grub. Is rootflags even a valid option?

Edit: I do see GRUB_BTRFS_ROOTFLAGS in /etc/default/grub-btrfs/config, but mine is the default of "".

sure looks like it, its in there for some reason.

❱cat /proc/cmdline
BOOT_IMAGE=/@/boot/vmlinuz-6.9-x86_64 root=UUID=5bf86f84-a752-4841-bcba-21f873673765 rw rootflags=subvol=@ quiet splash udev.log_priority=3

That was what i was wanting to talk about, the grub restore menu and its usage, but seem to have got sidetracked with fear of the fact i may have messed up the system by using the timeshift restore.

I shall just test them both (grub menu & timeshift restore) and see what i can see. I don’t know what I’m doing any more than a slightly above layman.

so if i use the grub menu i cant then use the timeshift restore?

So what do i do after using the grub menu restore so i can use timeshift restore again?

To reiterate, btrfs-grub was made without even knowing Timeshift would exist, it just detects btrfs snapshots, and automatically tries boot to them, placing them in your GRUB menu.

Ignore, or even remove, the package btrfs-grub, and the option to boot them wouldn’t exist. Use Timeshift and it’s restore, as much as you want. (Booting normally.)

Yes. I would stay clear of this altogether.

There is no grub menu restore. You are just booting into Timeshift’s created subvolume, which it was not designed to do.

Maybe someone else can explain this better than I without getting into what happens at the filesystem level. I can only say you start creating this mess of snapshots, with what would seem like a random layout of parent/child volumes all over the place. I described it as a tree of snapshots. Not this linear date organised layout Timeshift uses.

(Along with your /boot/grub/grub.cfg, among other things, using the long Timeshift subvol names that drive people like me mad, and likely break other things.)

I just called it a “restore” so we knew exactly what i was referring to.

I think i understand what btrfs-grub is and what it does. I would just stick to the timeshift restore, but the whole point is what happens if the systems gets borked and i cant boot it at all past grub? this just seemed like a nice ability.

I suppose the worse would be having to boot from “other” and manually send a snapshot that i do want to use and replace the /@ with it. I wouldn’t even have to worry about the read only or read write status as timeshift snapshots don’t even use it ^^. Or i could edit the mount in grub to point at the snapshot i want it to boot from (but surly that is all btrfs-grub is doing more or less? no?

It just seemed like a nice ability to have, pity.

I’ve used it, it can be handy. But I do not continue to use it, I get or change what I need, then get out.

If you rendered your current volume unbootable or whatever, you can still boot another snapshot through GRUB, and even restore it properly. But unfortunately, it is not with the restore button, and takes some manual steps. (Almost the same steps with a live boot.)

Well, can you point me to an up-to-date good description of one of the ways to restore the system from the outside (from live boot)? as im getting the feeling its not as simple as just switching the snapshot you want with the old root snapshot that you were using. Im suspecting it might work but its the incremental path, parent and child that is where the confusion is going to be and i’v only just had a week of scratching my head over these things already.

I would like to assume that i will at some point need to do it this way though and would like to at least have some idea.

If you boot into a rw-snapshot, you start to change it. So after that it is not any more your good point for rollback.

Manual rollback is possible:

Try to :mag: in the forum for “btrfs rollback”

1 Like

The file you’re looking for is /boot/grub/grub.cfg.