Boot Failure After Snapper Rollback on openSUSE Leap: A Diagnostic & Fix Guide

Recognizable Condition

After performing a Snapper rollback on a Btrfs‑rooted openSUSE Leap system, the machine drops into an emergency shell on boot. The kernel prints messages such as:

cannot find root device UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
mounting /dev/disk/by-id/... failed

or the GRUB2 menu shows a stale entry pointing to a snapshot that no longer exists.

Root‑Cause & Diagnostic Table

Cause	Diagnostic Indicator
Wrong default subvolume	"btrfs subvolume get-default /" returns an ID that is not the @ subvolume.
Out‑of‑date GRUB2 entry	GRUB2 configuration references a snapshot subvolume ID that is missing.
Corrupted snapshot	Snapper list shows the snapshot but mounting fails; "snapper status" reports a conflict.

Ordered Diagnostic Checks

1. Boot into an emergency shell or rescue environment. If you can’t reach a shell, boot from a live USB and chroot into the system’s root partition.

2. Verify the current default subvolume.

   # btrfs subvolume get-default /  # runs from the live environment or emergency shell
   # Expected output: ID of the @ subvolume (usually 5 or 6)
   

   Check the output against the list of subvolumes.

3. List all Btrfs subvolumes on the root filesystem.

   # btrfs subvolume list / | grep -E "@|snap"
   

   Identify the ID of the @ subvolume (e.g., 6) and any recent Snapper snapshots.

4. Check Snapper snapshot list.

   # snapper list
   # ID  |  TIMESTAMP  |  TYPE      |  DESCRIPTION
   # 10  | 2026-10-15 |  rollback  |  after package update
   

5. Inspect the GRUB2 configuration.

   # cat /boot/grub2/grub.cfg | grep -i snapshot
   

   Look for lines containing subvolid= that reference a snapshot ID.

Fixes Tied to Findings

1. Wrong default subvolume.

   If btrfs subvolume get-default / does not return the @ subvolume ID, reset it:

   # btrfs subvolume set-default 6 /   # replace 6 with the correct ID
   # Verify:
   # btrfs subvolume get-default /
   

   Reboot to see if the system starts normally.

2. Out‑of‑date GRUB2 entry.

   Regenerate the GRUB2 configuration so it points to the current default subvolume:

   # grub2-mkconfig -o /boot/grub2/grub.cfg
   # Verify the new entry contains the correct subvolid.
   

   Reboot. The system should now load the right snapshot.

3. Corrupted snapshot.

   Boot into a read‑only snapshot that is known to be healthy (e.g., snapshot 9). Then run:

   # snapper rollback 9
   

   After rollback, repeat the default subvolume and GRUB2 steps above. If the snapshot is irreparably corrupted, restore from a backup or reinstall the affected packages.

Escalation Criteria

• After applying all fixes, if the system still fails to boot, suspect kernel‑level or hardware issues unrelated to Snapper.
• If the root UUID changes in the kernel log, verify that the /etc/fstab and /boot/grub2/grub.cfg entries match the current UUID.
• When changes to Btrfs subvolumes cause data loss or inconsistency, restore from a recent backup.

Practical Verification Steps

1. After reboot, run:

   # btrfs subvolume get-default /
   # Expected: ID 6 (or the ID you set)
   

2. Confirm the root filesystem mounts correctly:

   # df -h / | grep /dev/sd
   

3. Check Snapper status:

   # snapper status
   # Should report "No conflicts" and the current snapshot ID.
   

Limitations & Risks

• Altering the default subvolume while the filesystem is mounted can corrupt data. Always perform these operations from a live CD or rescue environment.
• Setting the default to a snapshot that lacks a valid @ subvolume will lock you out of the system. Verify the snapshot contains a proper root directory before setting it as default.
• The guidance assumes openSUSE Leap 15.x with Btrfs root and Snapper 0.4+. Versions differ in command syntax; consult the relevant documentation for your release.