[SOLVED] RW snapshots seem to be mounted as RO

[FGD-Garuda]

Hello,

Just started testing booting from snapshots. It boots the kernel part fine. But it jams almost at the time it should start SDDM. Actually SDDM fails to start, among many other things.

Looking at journalctl -xb shows me a bunch of errors that all seem to be related with read-only file system.
dmesg.service fails at step STDOUT spawning /usr/bin/savelog: Read-only file system.

And there are many others like that, /var/log is read-only, etc...

I triple checked my snapshots and they are RW, I can write into them and btrfs subvol show of those snapshots display no flags at all.

How do you guys setup your system to boot flawlessly into snapshots?

Thanks!

[Antynea]

Hello,

Do you make your own snapshots, or do you use a third party software (timeshift, snapper...) ?

You can use the commands below to detect a read-only mounted snapshot :

Check if a kernel parameter is wrong :
cat /proc/cmdline
For example :
root=UUID=c9543c13-681c-4233-b5f6-c1a5578406ef rw loglevel=3 quiet
rw option is present, so the kernel has mounted your partition / in writable mode.

Check that your mounting point for /usr/bin is mounted in writable mode.
findmnt -l
for example:
/ /dev/sda2 btrfs rw,relatime,space_cache,subvolid=5,subvol=/
rw is present, means to be mount in writable mode.

Although the system may have mounted your partitions in writable mode, the file system may be in read-only mode by default.
Check it with :
btrfs property get / ro
Replace "/" with the correct mounting point for /usr/bin
ro=false means snapshot is in writable mode.

[FGD-Garuda]

Tnx for the super quick come back! :)

I do make my own snapshots, either manually from CLI or using very simple bash scripts I made that I trigger manually on ad-hoc purposes or that are triggered by cron on a specific time schedule. I do not use anything else, grub-btrfs being the only "3rd party" I am using now. The snapshots I am testing with grub-btrfs are pure manual CLI commands that I type, not using scripts.

I assume the validations you posted must be made on a snapshot I am trying to boot from, which I believe I could do through a second TTY session after it hangs. I was able to log into one this morning so I will check that right away.

As a comparison though, and maybe you will find something odd in the below, this is what I do show on my running non-snapshotted system, so booting normally through @ and @home subvols:

$ cat /proc/cmdline
BOOT_IMAGE=/@/boot/vmlinuz-5.8.0-33-generic root=/dev/disk/by-id/ata-CT1000MX500SSD1_1918E1FF0D5E-part1 ro quiet splash showopts rootflags=subvol=@

I have always used the ro kernel parm, don't know if that could be the issue with btrfs-grub.

$ findmnt -l
TARGET                     SOURCE        FSTYPE     OPTIONS
/                          /dev/sdb1[/@] btrfs      rw,noatime,ssd,space_cache,subvolid=1879,subvol=/@

Everything in findmnt -l is rw.

$ sudo btrfs property get / ro
ro=false

Now I will boot from a snapshot, switch TTY and issue those commands, I will report back.

[FGD-Garuda]

Yup! The snapshot, not the fs, is mounted ro.

$ sudo btrfs property get / ro
ro=false

$ findmnt -l
TARGET                     SOURCE        FSTYPE     OPTIONS
/                          /dev/sdb1[/@snapshots/@.test] btrfs      ro,relatime,ssd,space_cache,subvolid=1872,subvol=/@snapshots/@.test

$ cat /proc/cmdline
BOOT_IMAGE=/@snapshots@.test/boot/vmlinuz-5.8.0-33-generic root=/dev/sdb1 rw ro quiet splash showopts acpi_enforce_resources=lax rootflags=subvol=@snapshots/@.test

Now I see both rw and ro in the kernel line, I will remove the ro, the source should be from my 40_custom grub config file.
Also I see grub-btrfs brings back an old kernel parm (acpi_enforce_resources=lax) which I am not using anymore. This is a funny one as I deleted that parm from my custom config file and also from grub.cfg. I will have to dig to find where grub-btrfs takes this from. But that option will not prevent booting. The ro could be wrong, let me try by removing it from my custom file, regenerating and rebooting.

[FGD-Garuda]

Working!!! :)

Oh my god I totally forgot about /etc/default/grub file. In there you gotta make sure you don't have ro in the GRUB_CMDLINE_LINUX_DEFAULT= line. Which I did. I also had my acpi_enforce_resources=lax in there, so that was the culprit.

Fixed those 2 and voilà, I'm in a snapshot right now. :)

Now I all I have to do is try to boot a snapshot with /home inside the snapshot, so I won't need to manually change my fstab in every snapshot in order to mount the @home subvol corresponding to that snapshot. I'll try that, if I fail I'll post a different discussion.

To sum all up, there are logical pre-requisites to make this work. You have to make sure there is no ro kernel parm passed on and make sure your /etc/default/grub file won't make grub-btrfs pick anything you wouldn't want.

I'm hoping this discussion will help other people with similar issue.

[FGD-Garuda]

Since btrfsck check does not repair the fs and --repair option only runs on unmounted fs, then there is no need for that ro kernel parm, am I correct?

[Kr1ss-XD]

As far as I understand, a Btrfs file system isn't fsck'ed during boot/mounting. I'd say if there's no special reason (e.g. forensical examination or recovery) it's safe (and recommended) to omit ro.