System is unbootable; BTRFSonLUKS, snapshots not working

[ez_does_it]

Good evening all,

I followed the wonderful guide written by @2000 found here:

HOWTO - GPT/UEFI install with full disk encryption: BTRFSonLUKS with separate root, home and pkg subvolumes; hibernation with a swapfile; auto-snapshots with easy system rollback (GUI); boot into snapshots

Warning: Most of what is done here in this tutorial is now already implemented inside calamares installer! but … it can be useful for pure arch install… warning added by joekamprad 21.5.2022 Inspired by some posts from @TomZ I decided to have a (re-)go at btrfs, test its snapshot capabilities and the ease of restoring these, try different subvolume setups and check if calamares allows for an encrypted install. As a result I have decided to make the following my new default type of install…

All was moving swimmingly until I tried to install zoom and it caused a crash. At first, I would get to the sddm login and once I input my password I would get a system freeze.

I tried booting into my grub snapshots. I selected one, and now the system won’t boot to sddm. It stalls after the grub image/snapshot selector where it typically should boot to sddm.

I got my liveiso to boot from and I think I figured out why I’m having the issue where the snapshot isn’t booting. After installing timeshift gui and browsing through the snapshots folder, I find that there are indeed snapshot directories in the main directory, but timeshift doesn’t recognize any of the snapshot directories as snapshots; that is to say there are snapshot directories, full with snapshots, however, for whatever reason, timeshift doesn’t recognize the snapshot in a way where it will use to restore. Instead, all that is said on the GUI and CLI is “no snapshots found”, despite the directory being full with snapshots.

Could someone suggest a fix to turn these snapshot directories into actual snapshots I can use?

Any feedback would be appreciated.

[2000]

I suspect something is wrong with your @ subvolume. You could try to restore a snapshot manually.

1. Boot into the live environment
2. Rename (mv) or copy one of your working snapshots to @
3. Reboot

Timeshift should then be able to pick up your other snapshots.

---

Btw, if you ever need to chroot your btrfs system from a liveiso, see section “How to RESTORE a snapshot” int the Wiki.

[Edit] Oh, and welcome to the community!

[ez_does_it]

Thanks for the quick reply. To date, this is my favorite distro, so I’m glad to be part of the community.

Is there any way to diagnose what might be wrong with a given volume? I know it’s fairly technically high level, but is there a way to repartition or replace the volume data to correct the error? Or is the better option just to do a reinstall?

You could try to restore a snapshot manually.

By following your steps, would I be doing what I suggested above, or is that just a suggestion on how to manually restore a snapshot?

Thanks

[2000]

@ez_does_it

Is there any way to diagnose what might be wrong with a given volume?

Sure, but given the amount of possibilities and the fact that you may have functioning snapshots I personally think this question is purely academic.
If your btrfs filesystem contains a @ subvolume, why don’t you rename it to e. g. @_checklater and restore a working snapshot by renaming (per mv command for instance) it to @ first. You could then run all sort of checks on the subvolume @_checklater later on.

@ez_does_it

I know it’s fairly technically high level, but is there a way to repartition or replace the volume data to correct the error?

@ez_does_it

By following your steps, would I be doing what I suggested above, or is that just a suggestion on how to manually restore a snapshot?

Both! Assuming the error isn’t hardware related (failing storage etc.), replacing/generating a @ subvolume with a functioning snapshot subvolume does exactly that; it “replaces the volume data to correct the error”. If all goes well there’s no need to repartition or reinstall anything.