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