Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deleting snapshot causes loss of @ subvolume when restoring via GRUB #362

Open
0iSuck-at-coding0 opened this issue Jan 27, 2025 · 0 comments

Comments

@0iSuck-at-coding0
Copy link

0iSuck-at-coding0 commented Jan 27, 2025

Yesterday, 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 issue post on GitHub. Which means that I probably made some mistakes here. If I did feel free to correct my ways. I didn't know if screenshots 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 the screenshots. I also did not know what forum to post to but I picked this one because when I did not restore from the GRUB menu, everything was fine.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant