On Mon, Mar 18, 2024 at 12:39 PM Roger Oberholtzer
<roger.oberholtzer@gmail.com> wrote:
>
> Hmmm. I see.
>
> So if I am happy with snapshot 1406, I would 'snapper rollback 1406' to make that the current content?
>

Correct. Or boot into this snapshot and do "snapper rollback".

> 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