You are not logged in.

#1 2025-01-30 20:13:37

iSuck_at_Arch
Member
Registered: 2025-01-27
Posts: 1

Deleting snapshot causes loss of @ subvolume when restoring via GRUB

I was trying to get grub-btrfs working on my Arch Linux system. I ran a test where I created a snapshot using the Timeshift GUI, then installed a package. Everything was going well; I booted into the snapshot using GRUB and sure enough the package was no longer there(which is the expected behavior). I then restored the same snapshot that I used GRUB to boot into and then I restarted. Up until that point everything was fine and I decided to do some housekeeping on my machine. I deleted the snapshot that my system restored to, and after deleting that snapshot my whole @ subvolume went with it.

After that I did some testing and my findings were this: After I restored(using the exact same method above) I did "mount | grep btrfs." I discovered that my @ subvolume was not mounted and that the snapshot was mounted instead. I ran another test on a freshly installed system, where I made two snapshots one after the other. I used GRUB to boot into one snapshot and restored the other. This worked and my @ subvolume was mounted just as expected. (Just so you know, I did the same installed package test as stated above and they both passed, which means that I was indeed restoring snapshots).

I was trying to search around for this behavior and I could not find anything. If someone else did bring it up; I would like someone to point me in that direction. If this behavior is expected after booting into a snapshot from GRUB, I would like an explanation as to why. If it is not then I guess that might be a problem.

I have a last unrelated question: When I boot into a snapshot from GRUB, will it only restore the @ subvolume and not the @ home subvolume? The reason I ask, is that I tried to change my wallpaper and restore to the original wallpaper but that did not work but the packages thing did.

P.S: This is my first post on the Arch Wiki. I probably  made some mistakes here. If I did feel free to correct my ways. I didn't know if any command outputs would be helpful because I feel like, what I said here was pretty self explanatory. But feel free to ask, if you want to see them . Also, I posted an issue on  the GitHub for grub-btrfs, and got no response after three days. I would've waited longer(like a week or so)  but  I'm pretty sure the project is pretty much inactive. If there is a more appropriate place  to post this issue, feel free to direct me.

**UPDATE**

Instead of using Timeshift, I decided to use snapper with btrfs-assistant. I ran through the same tests I did above, and it worked flawlessly! I also made some new discoveries.

Timeshift differs with snapper in the way that they store the snapshots and mount them from the grub menu. Timeshift mounts the snapshot directory as the root subvolume. Meanwhile, it would seem that snapper is mounting the snapshots subvolume as the root subvolume. I think, in my case, GRUB misinterpreted the Timeshift directory as my root subvolume.

In my opinion, this particular issue is probably nobodies fault. However, I will agree that snapper's way of storing and mounting subvolumes is better because it caused me no problems with regular use. If I were to blame one thing, it would be the fact that the Timeshift GUI allowed me to delete the snapshot that was acting as my root subvolume. I noticed that btrfs-assistant will not allow you to create or delete snapshots when a snapshot is mounted.

P.S. I am not a technical person by any means. If you see any false information here, feel free to call me out. I will happily change any false information presented. These are just the observations I have made and how they looked to me.

Last edited by iSuck_at_Arch (2025-02-03 23:17:07)

Offline

Board footer

Powered by FluxBB