Hmmm. I see.

So if I am happy with snapshot 1406, I would 'snapper rollback 1406' to make that the current content?

I ask because snapper seems very powerful to the point where I get suspicious. This is the computer version of "measure twice, cut once".



On Mon, Mar 18, 2024 at 10:05 AM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Mon, Mar 18, 2024 at 11:03 AM Roger Oberholtzer
<roger.oberholtzer@gmail.com> wrote:
>
> I have a strange (to me) situation on a Tumbleweed system with btrfs filesystems. Due to issues updating to KDE6, I had to rollback. And the rollback did not really roll back. So I snapper rm'd the  various pre/post items so that the snapshot before the attempted update was the default one. It is now sorted so that it boots into the snapshot that I want. All of the file systems are mounted rw. I see this in the mount command. There are no ro file systems (except /boot/uefi). However, when I try to write to most of the file systems, it complains that they are read-only.

Snapshots *are* read-only by definition. To revert to snapshot content
you need to perform rollback which clones snapshot into writable
subvolume.

> At the mount level, they are not mounted read-only. So it must be the case that somewhere there is a flag that the file systems are read-only. I've only encountered this at the mount level. I tried a mount -oremount,rw on them, and it completes without a complaint. But there is no change. And as the mount command lists that they are rw, this is no surprise. I am bnot mounting into a read-only snapshot. Or at least I am not choosing that when booting. It is just the default snapshot that is being used.
>
> Where else other than via mount can a file system be made read-only? And how to correct that?
>
> --
> Roger Oberholtzer


--
Roger Oberholtzer