this post was submitted on 15 Sep 2024
7 points (76.9% liked)

Arch Linux

7841 readers
7 users here now

The beloved lightweight distro

founded 4 years ago
MODERATORS
 

Hi everyone, hope you guys have a nice day! Long story short. I hop from opensuse tumbleweed to arch recently. I want to setup snapper so it work like on opensuse just to be safe. Even on opensuse the rolling release did kill my system few time. I run into this part on the arch wiki.

Note: If you are using the suggested Btrfs partition layout from archinstall then the @.snapshots subvolume will already be mounted to /.snapshots, and the snapper create-config command will fail [1]. To use the @.snapshots subvolume for Snapper backups, do the following:

Unmount the @.snapshots subvolume and delete the existing mountpoint.
Create the Snapper config.
Delete the subvolume created by Snapper.
Re-create the /.snapshots mount point and re-mount the @.snapshots subvolume.

I did installed arch via archinstall but I am not really experience with the btrfs files system nor mount or unmount stuff so as I expected I killed my system. I reinstalled arch and not sure how to setup snapper without pull my hair out again. Any help would be appreciate thank!

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 2 points 3 months ago

Here is what chatgpt says about your error message:

In Btrfs (a modern Linux filesystem), subvolumes can be mounted using either their subvolume ID (subvolid) or their subvolume path (subvol):

•	Mounting by subvolid: Uses a unique numerical identifier assigned to each subvolume.
•	Mounting by subvolume path: Uses the filesystem path to the subvolume.

Why is this important when performing a rollback?

When you mount by subvolid, the mount point is tied to a specific subvolume ID. If you perform a rollback or restore, the subvolume IDs can change because new subvolumes (snapshots) are created or old ones are replaced. This can lead to unexpected behavior, such as the system booting into the wrong snapshot or failing to boot altogether.

Mounting by subvolume path is more reliable in this context because the path remains consistent even if the underlying subvolume ID changes.

Did you do something wrong?

Not necessarily. Mounting by subvolid isn’t incorrect in general use. However, when dealing with rollbacks or restores, it can cause issues due to the reasons mentioned above. The warning is advising you to switch to mounting by subvolume path to ensure the rollback proceeds smoothly.

What should you do next?

It’s recommended to switch your system to mount by subvolume path before proceeding with the rollback. Here’s how you can do that:

Steps to Switch from Subvolid to Subvolume Path

1.	Identify Your Current Subvolume Path:
•	Open a terminal.
•	Run the command:

sudo btrfs subvolume list /

•	Look for the subvolume with the ID you’re currently mounting. Note its path.

2.	Edit the /etc/fstab File:
•	Back up your current fstab file:

sudo cp /etc/fstab /etc/fstab.backup

•	Open the fstab file with a text editor:

sudo nano /etc/fstab

•	Locate the line that mounts your Btrfs filesystem. It will have an option like subvolid=....
•	Change subvolid=... to subvol=... and specify the subvolume path you noted earlier. For example:

Before:

UUID=xxxxxxx / btrfs defaults,subvolid=256 0 0

After:

UUID=xxxxxxx / btrfs defaults,subvol=/@ 0 0