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. 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
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
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
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
I am booted into it. snapper rollback says: Ambit is transactional. Active snapshot is already default snapshot. snapper ls puts a star after the snapshot number. For some reason, this is the only snapshot that exists (a pre/post pair made by zypper) after the one from the initial install (#0) . All previous ones have been purged. On Mon, Mar 18, 2024 at 10:51 AM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
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
-- Roger Oberholtzer
On Mon, Mar 18, 2024 at 1:21 PM Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
I am booted into it. snapper rollback says:
Ambit is transactional. Active snapshot is already default snapshot.
Show btrfs subvolume list btrfs subvolume get-default snapper list lsblk -f
snapper ls puts a star after the snapshot number.
For some reason, this is the only snapshot that exists (a pre/post pair made by zypper) after the one from the initial install (#0) . All previous ones have been purged.
On Mon, Mar 18, 2024 at 10:51 AM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
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
-- Roger Oberholtzer
On Mon, Mar 18, 2024 at 12:00 PM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
Show
btrfs subvolume list
ID 256 gen 32 top level 5 path @ ID 258 gen 2793049 top level 256 path @/var ID 259 gen 2792589 top level 256 path @/usr/local ID 260 gen 2792932 top level 256 path @/tmp ID 261 gen 2788070 top level 256 path @/srv ID 262 gen 2792933 top level 256 path @/root ID 263 gen 2793049 top level 256 path @/opt ID 264 gen 2793048 top level 256 path @/home ID 265 gen 2790045 top level 256 path @/boot/grub2/x86_64-efi ID 266 gen 2790045 top level 256 path @/boot/grub2/i386-pc ID 267 gen 2792932 top level 256 path @/.snapshots ID 1873 gen 2178925 top level 258 path @/var/lib/docker/btrfs/subvolumes/b8e0c68b7ab52b2c7108e1fe23ca006d20c01e08323c84c91da09d7fecc9e74a ID 1874 gen 2178925 top level 258 path @/var/lib/docker/btrfs/subvolumes/376e4230fa012968c602e6003a24c0836ece125c01a424178b3e3f47501b394c ID 1875 gen 2178925 top level 258 path @/var/lib/docker/btrfs/subvolumes/000fb2a53702b6e1d6cc38080e0e713d144ff8470b50bcddc92a47714adb141c ID 1876 gen 2178925 top level 258 path @/var/lib/docker/btrfs/subvolumes/e7e12c39907dac259384564ec346bfe29218705db326eddd7af403238fca4457 ID 1877 gen 2178925 top level 258 path @/var/lib/docker/btrfs/subvolumes/5d6ad41461e51fddb0b4bb9fa55b5c70731e49570ff1b9961ace9200094146e9 ID 1878 gen 2178925 top level 258 path @/var/lib/docker/btrfs/subvolumes/dc572a4f436e34734cad6032a0e95045e7787d2eaf10d29ccb7df11150247dbf ID 1879 gen 2178925 top level 258 path @/var/lib/docker/btrfs/subvolumes/1dd4fa4d14c5812b01f60bee9b11a8187541c8d667ebc9a02cc100ac6ccb6d4f ID 1880 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/7065047d8424ae6e9806c92d434db7f385b67b2a4af79b1efdd31b76462fae5c ID 1881 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/77daab1f179e9f253c6349f1d55606915ce69003c96c7c264a737138be448055 ID 1882 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/85924c5aa9456fac898a9efa799f8bc8abffc0be29953ff076cb607199df8fcc ID 1883 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/26efd3e91e24a62ca2b009c86505c1123af35287e5efa88a687bc3f31f139b06-init ID 1884 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/26efd3e91e24a62ca2b009c86505c1123af35287e5efa88a687bc3f31f139b06 ID 1885 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/1ca53dbdf061f637c6bb2c1901f0ef1ef867a9942b76b4e96c0834b6c3ec6048-init ID 1886 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/1ca53dbdf061f637c6bb2c1901f0ef1ef867a9942b76b4e96c0834b6c3ec6048 ID 1887 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/c06e28831e2eb180699ca6b2c76d053b4911aecc092db0eb52d440b43b2dbd5f-init ID 1888 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/c06e28831e2eb180699ca6b2c76d053b4911aecc092db0eb52d440b43b2dbd5f ID 1889 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/0be63bf5c563f6dabd77b859b7b830fac34df01336a0e265144e9904ffeefd41-init ID 1890 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/0be63bf5c563f6dabd77b859b7b830fac34df01336a0e265144e9904ffeefd41 ID 1891 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/7ec39b6885a13b37fc10661c4eacead55f6d13e0fafebb0cb66a40507d2ad532-init ID 1892 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/7ec39b6885a13b37fc10661c4eacead55f6d13e0fafebb0cb66a40507d2ad532 ID 1893 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/cc09a7e4aeba00c45b3d2f071198d87687d7baaaff2d895ddf1ac3703670da78-init ID 1894 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/cc09a7e4aeba00c45b3d2f071198d87687d7baaaff2d895ddf1ac3703670da78 ID 1895 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/7e63d5d43ddacb66850450b370c2457566fa015e2e9e7302ae92a773418bb9af-init ID 1896 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/7e63d5d43ddacb66850450b370c2457566fa015e2e9e7302ae92a773418bb9af ID 1897 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/bf78ed7c6c05280d4d741a7aae8defbf66f15dfa01a2aff415af94d35aae93d0-init ID 1898 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/bf78ed7c6c05280d4d741a7aae8defbf66f15dfa01a2aff415af94d35aae93d0 ID 1899 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/da6f38dd34e363e27e30bed308cba617fe8067e0253c69228af3fbbc8095c75c-init ID 1900 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/da6f38dd34e363e27e30bed308cba617fe8067e0253c69228af3fbbc8095c75c ID 1901 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/e296382a1285a9671d3cc2d52b41aff760ccebf63de6a6e034418ad2e9162303-init ID 1902 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/e296382a1285a9671d3cc2d52b41aff760ccebf63de6a6e034418ad2e9162303 ID 1909 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/0f0e184ce9fb4f0c858a7ab10efa57630da9ed3282cb116dfb86a5599b367f14-init ID 1910 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/0f0e184ce9fb4f0c858a7ab10efa57630da9ed3282cb116dfb86a5599b367f14 ID 1911 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/7dae94998a425a4cdc655193d0948c0fc75a1259e9f5b81b75d766e50bb06c93-init ID 1912 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/7dae94998a425a4cdc655193d0948c0fc75a1259e9f5b81b75d766e50bb06c93 ID 1913 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/146693cd1a833d7fdfe5f72e1a92a91032bf90730c418cc7280602b1c5558449-init ID 1914 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/146693cd1a833d7fdfe5f72e1a92a91032bf90730c418cc7280602b1c5558449 ID 1915 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/08cb13cd4f7b658203229cedb8dc28f3256f57a7b11f24b319df574f38a26aca-init ID 1916 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/08cb13cd4f7b658203229cedb8dc28f3256f57a7b11f24b319df574f38a26aca ID 1917 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/6ac41b371fff09739aedf60da1a422124e44dee7578151ad5df0f5bf94696b29-init ID 1918 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/6ac41b371fff09739aedf60da1a422124e44dee7578151ad5df0f5bf94696b29 ID 1919 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/76979eab5f5cc0e436d6acdac083b1680ed958a824d3fb5a2b5db3024a5589cc-init ID 1920 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/76979eab5f5cc0e436d6acdac083b1680ed958a824d3fb5a2b5db3024a5589cc ID 1921 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/3dbd4c22b34f7f895102c3c6924728667195d9b116a8c60fe61e9e3731c663f6-init ID 1922 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/3dbd4c22b34f7f895102c3c6924728667195d9b116a8c60fe61e9e3731c663f6 ID 1952 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/4022173c8c4c87c7d6cec6789db336867f9c950b222202fa0ffc815e05964ae4-init ID 1953 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/4022173c8c4c87c7d6cec6789db336867f9c950b222202fa0ffc815e05964ae4 ID 1960 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/76333786da57ce9a6e83f0a47381aada51894ddebc45d86bea6c140ae6582e12-init ID 1961 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/76333786da57ce9a6e83f0a47381aada51894ddebc45d86bea6c140ae6582e12 ID 1962 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/e05936ac0a4f0811248e4395ddf409987f73b7efa882638142ea6920e3302550-init ID 1963 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/e05936ac0a4f0811248e4395ddf409987f73b7efa882638142ea6920e3302550 ID 1964 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/2177db6d0978d71e32ad0814f427b81f085e1f6c6c15e551f626c7ee43b75865-init ID 1965 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/2177db6d0978d71e32ad0814f427b81f085e1f6c6c15e551f626c7ee43b75865 ID 1966 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/350cd4a940e24406f2599ef4a415405a6ad84c9f1726f05d75545599fa33ba2c-init ID 1967 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/350cd4a940e24406f2599ef4a415405a6ad84c9f1726f05d75545599fa33ba2c ID 1968 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/b23036d89498bb7d14aa81319f31c0688554765ab8a15e5164341e45912379fd-init ID 1969 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/b23036d89498bb7d14aa81319f31c0688554765ab8a15e5164341e45912379fd ID 1970 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/ca0ba853ccf82c6c56cc2c746171a3be8f4d201eb8730bf4b5b2e8930a8d1cd0-init ID 1971 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/ca0ba853ccf82c6c56cc2c746171a3be8f4d201eb8730bf4b5b2e8930a8d1cd0 ID 1972 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/bf83cdad8560fb1dfe8103c3fea24da4452921f4fea0cc69f9099fdb76abdc8d-init ID 1973 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/bf83cdad8560fb1dfe8103c3fea24da4452921f4fea0cc69f9099fdb76abdc8d ID 1974 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/1a3c4f0a62c83ec0736ad4bc9f34961b3b3ea58440f03d1528254e7ca8769028-init ID 1975 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/1a3c4f0a62c83ec0736ad4bc9f34961b3b3ea58440f03d1528254e7ca8769028 ID 1976 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/46789fcea7e3379b76bd8013d2b6684ad1de6258b2050f4579abd5d4dbed9aac-init ID 1977 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/46789fcea7e3379b76bd8013d2b6684ad1de6258b2050f4579abd5d4dbed9aac ID 1978 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/0d80161507f2d72854a563dc739eca3a7ee41d58720eba325bd6d633f4cc57f6-init ID 1979 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/0d80161507f2d72854a563dc739eca3a7ee41d58720eba325bd6d633f4cc57f6 ID 1980 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/aaa9176d8edf5c4729e17c655fcff765120fa0185fb2eeadd4aac83c9d12673c-init ID 1981 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/aaa9176d8edf5c4729e17c655fcff765120fa0185fb2eeadd4aac83c9d12673c ID 1982 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/34e405fbcc0f5477f75e84c386c99154031b3ad4a9b08779a6eb82182f9cfcce-init ID 1983 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/34e405fbcc0f5477f75e84c386c99154031b3ad4a9b08779a6eb82182f9cfcce ID 1984 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/f2f5dd27a497ac08a22713b0cd7efb01de4b8646c76501417869b3a9bca9a9c9-init ID 1985 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/f2f5dd27a497ac08a22713b0cd7efb01de4b8646c76501417869b3a9bca9a9c9 ID 1986 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/5c75769485df3dd06944224a8356cfccbcda33536cdc28bdbad34a69662643ae-init ID 1987 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/5c75769485df3dd06944224a8356cfccbcda33536cdc28bdbad34a69662643ae ID 1988 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/82add292cfdee3313605401155fff171b2a5bc37bfa5fe4b0d2092d14a4d57cd-init ID 1989 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/82add292cfdee3313605401155fff171b2a5bc37bfa5fe4b0d2092d14a4d57cd ID 1990 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/2ee48ce456b9bfc0e022215e97ccdad7e227ba6562ad72f588fc416e787f9fe7-init ID 1991 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/2ee48ce456b9bfc0e022215e97ccdad7e227ba6562ad72f588fc416e787f9fe7 ID 1992 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/05d048cb5e27a3fe488319cf418de23a3c6c11b7f7046fbb2af07a5e33e787b0-init ID 1993 gen 2444022 top level 258 path @/var/lib/docker/btrfs/subvolumes/05d048cb5e27a3fe488319cf418de23a3c6c11b7f7046fbb2af07a5e33e787b0 ID 2978 gen 2788072 top level 258 path @/var/lib/machines ID 3387 gen 2784462 top level 267 path @/.snapshots/1405/snapshot ID 3388 gen 2784466 top level 267 path @/.snapshots/1406/snapshot btrfs subvolume get-default
ID 3388 gen 2784466 top level 267 path @/.snapshots/1406/snapshot snapper list
# | Type | Pre # | Date | User | Cleanup | Description | Userdata ------+--------+-------+---------------------------------+------+---------+--------------+------------- 0 | single | | | root | | current | 1405 | pre | | Wed 13 Mar 2024 12:15:29 PM CET | root | number | zypp(zypper) | important=no 1406* | post | 1405 | Wed 13 Mar 2024 12:16:02 PM CET | root | number | | important=no
lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sda nvme0n1 ├─nvme0n1p1 vfat FAT32 ESP 0020-DBBE 580.4M 10% /boot/efi ├─nvme0n1p2 ├─nvme0n1p3 btrfs 6df208b6-6d8d-4798-b9d1-12d3c519ee3a 31.9G 93% /var/lib/docker/btrfs │ /var │ /usr/local │ /tmp │ /boot/grub2/x86_64-efi │ /opt │ /home │ /root │ /srv │ /boot/grub2/i386-pc │ /.snapshots │ / └─nvme0n1p4 swap 1 9f5e92d4-b8d0-48e7-b16d-cd272e4e66a7 [SWAP] I've also looked at errors (btrfs device stats), and I don't see any. And there is nothing in the journal that I can see. I'm not sure what all the docker stuff is. It is installed. But I haven't used it in ages.
snapper ls puts a star after the snapshot number.
For some reason, this is the only snapshot that exists (a pre/post pair made by zypper) after the one from the initial install (#0) . All previous ones have been purged.
On Mon, Mar 18, 2024 at 10:51 AM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
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'
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
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
to make that the current content? 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. 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
-- Roger Oberholtzer
-- Roger Oberholtzer
On Mon, Mar 18, 2024 at 2:35 PM Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
ID 3388 gen 2784466 top level 267 path @/.snapshots/1406/snapshot
snapper list
# | Type | Pre # | Date | User | Cleanup | Description | Userdata ------+--------+-------+---------------------------------+------+---------+--------------+------------- 0 | single | | | root | | current | 1405 | pre | | Wed 13 Mar 2024 12:15:29 PM CET | root | number | zypp(zypper) | important=no 1406* | post | 1405 | Wed 13 Mar 2024 12:16:02 PM CET | root | number | | important=no
Is it Tumbleweed or MicroOS? Assuming it is Tumbleweed - I do not know what you did, but normally the default subvolume cannot be the snapshot you boot into. Try snapper rollback --ambit=classic
On Mon, Mar 18, 2024 at 1:24 PM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Mon, Mar 18, 2024 at 2:35 PM Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
ID 3388 gen 2784466 top level 267 path @/.snapshots/1406/snapshot
snapper list
# | Type | Pre # | Date | User | Cleanup
| Description | Userdata
------+--------+-------+---------------------------------+------+---------+--------------+-------------
0 | single | | | root | | current | 1405 | pre | | Wed 13 Mar 2024 12:15:29 PM CET | root | number | zypp(zypper) | important=no 1406* | post | 1405 | Wed 13 Mar 2024 12:16:02 PM CET | root | number | | important=no
Is it Tumbleweed or MicroOS?
Tumbleweed.
Assuming it is Tumbleweed - I do not know what you did, but normally the default subvolume cannot be the snapshot you boot into. Try
snapper rollback --ambit=classic
Seems rollback does not have this option. And it is not a global one. -- Roger Oberholtzer
On 18.03.2024 17:45, Roger Oberholtzer wrote:
snapper rollback --ambit=classic
Seems rollback does not have this option. And it is not a global one.
bor@tw:~> sudo snapper --ambit=classic rollback Ambit is classic. Creating read-only snapshot of default subvolume. (Snapshot 280.) Creating read-write snapshot of current subvolume. (Snapshot 282.) Setting default subvolume to snapshot 282. Client-side plugin '/usr/lib/snapper/plugins/10-sdbootutil.snapper' failed. Server-side plugin '/usr/lib/snapper/plugins/10-sdbootutil.snapper' failed. Server-side plugin '/usr/lib/snapper/plugins/10-sdbootutil.snapper' failed. bor@tw:~>
On 2024-03-18 04:20, Roger Oberholtzer wrote:
I am booted into it. snapper rollback says:
Ambit is transactional. Active snapshot is already default snapshot.
snapper ls puts a star after the snapshot number.
For some reason, this is the only snapshot that exists (a pre/post pair made by zypper) after the one from the initial install (#0) . All previous ones have been purged.
Maybe because you removed all the rest, as per your initial post?
Sigh. I don't want to do a reinstall. All the software is set exactly as I want. It's one of (not the only) systems on which I develop software. Oh well. Time to extract all the needed information from it!
Why are you talking about this now? Andrei and I have been making suggestions of what you can try now, but all you have done is run commands Andrei suggested so we can get an idea what your system looks like right now. Doing a reinstall is the very last resort, and we are nowhere near there yet.
I still cannot believe that snapper cannot do whatever it does to allow changes. A new snapshot. Couldn't I make a snapshot via some other command than rollback?
Rollback is not a command. It is a snapper sub-command. "Snapper rollback" will do exactly what it says: When you boot into a previous snapshot (which is r/o), it will write that into the default, which is r/w -- except that it seems one cannot do a rollback when already booted into the default snapshot. So that leaves just one option, and if this does not work, I think a reinstall is your only choice. HOWEVER... DO NOT do this right away; give Andrei and others a chance to comment on my idea first. You are booted into snapshot 1406, so rollback to 1405: snapper rollback 1405 If this succeeds, it will set snapshot 1405 as the new default. (If it fails, I think you are out of options and a reinstall will be needed.) Verify this by running "snapper list". 1405 and 1406 will still be there, and there will (hopefully) be two new snapshots, with numbers higher than 1406. If that is the case, then: Reboot Before doing anything else, run snapper rollback 1406 which is the snapshot you want to have as your default. Reboot again, and verify that everything is as you want it to be. A reminder -- do NOT do this yet, until others have had a chance to give some feedback. So... Comments, Andrei (and anyone else who wishes)?
On Mon, Mar 18, 2024 at 5:43 PM Darryl Gregorash <raven@accesscomm.ca> wrote:
On 2024-03-18 04:20, Roger Oberholtzer wrote:
I am booted into it. snapper rollback says:
Ambit is transactional. Active snapshot is already default snapshot.
snapper ls puts a star after the snapshot number.
For some reason, this is the only snapshot that exists (a pre/post pair made by zypper) after the one from the initial install (#0) . All previous ones have been purged.
Maybe because you removed all the rest, as per your initial post?
Sigh. I don't want to do a reinstall. All the software is set exactly as I want. It's one of (not the only) systems on which I develop software. Oh well. Time to extract all the needed information from it!
Why are you talking about this now? Andrei and I have been making suggestions of what you can try now, but all you have done is run commands Andrei suggested so we can get an idea what your system looks like right now. Doing a reinstall is the very last resort, and we are nowhere near there yet.
The suggestion was to try the rollback. I did that and reported that it did not succeed. Did I miss another suggestion that was not perhaps going to totally mess up the filesystem? I also want to be sure I have collected all useful information off the system before trying a possibly destructive command. I've not had a chance to do that yet. Day job and all that.
I still cannot believe that snapper cannot do whatever it does to allow
changes. A new snapshot. Couldn't I make a snapshot via some other command than rollback? Rollback is not a command. It is a snapper sub-command. "Snapper rollback" will do exactly what it says: When you boot into a previous snapshot (which is r/o), it will write that into the default, which is r/w -- except that it seems one cannot do a rollback when already booted into the default snapshot. So that leaves just one option, and if this does not work, I think a reinstall is your only choice. HOWEVER... DO NOT do this right away; give Andrei and others a chance to comment on my idea first.
You are booted into snapshot 1406, so rollback to 1405: snapper rollback 1405 If this succeeds, it will set snapshot 1405 as the new default. (If it fails, I think you are out of options and a reinstall will be needed.) Verify this by running "snapper list". 1405 and 1406 will still be there, and there will (hopefully) be two new snapshots, with numbers higher than 1406. If that is the case, then:
Reboot Before doing anything else, run snapper rollback 1406 which is the snapshot you want to have as your default. Reboot again, and verify that everything is as you want it to be.
A reminder -- do NOT do this yet, until others have had a chance to give some feedback. So... Comments, Andrei (and anyone else who wishes)?
I was thinking something similar. But I guess I cannot make 1405 (a zypper pre) the default and boot into that. And then rollback 1406. Would I need to rollback 1405? I did not remove earlier snapshots. And they were not so old. They just went away as part of this. No idea why. I did remove later snapshots. Which in hindsight might not have been a good idea or even needed. One learns. -- Roger Oberholtzer
On 2024-03-19 10:10, Roger Oberholtzer wrote:
On Mon, Mar 18, 2024 at 5:43 PM Darryl Gregorash <...> wrote: On 2024-03-18 04:20, Roger Oberholtzer wrote: > I am booted into it. snapper rollback says: > > Ambit is transactional. > Active snapshot is already default snapshot. > > snapper ls puts a star after the snapshot number. > > For some reason, this is the only snapshot that exists (a pre/post pair > made by zypper) after the one from the initial install (#0) . All > previous ones have been purged. > Maybe because you removed all the rest, as per your initial post?
> Sigh. I don't want to do a reinstall. All the software is set exactly as I want. It's one of (not the only) systems on which I develop software. Oh well. Time to extract all the needed information from it!
Why are you talking about this now? Andrei and I have been making suggestions of what you can try now, but all you have done is run commands Andrei suggested so we can get an idea what your system looks like right now. Doing a reinstall is the very last resort, and we are nowhere near there yet.
The suggestion was to try the rollback. I did that and reported that it did not succeed. Did I miss another suggestion that was not perhaps going to totally mess up the filesystem? I also want to be sure I have collected all useful information off the system before trying a possibly destructive command. I've not had a chance to do that yet. Day job and all that.
Andrei suggested "sudo snapper --ambit=classic rollback" and showed an example on his machine. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
I tried that and it complained that the --ambit option was not recognized. I will try again when I next have access to the computer. On Tue, Mar 19, 2024 at 2:21 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2024-03-19 10:10, Roger Oberholtzer wrote:
On Mon, Mar 18, 2024 at 5:43 PM Darryl Gregorash <...> wrote: On 2024-03-18 04:20, Roger Oberholtzer wrote: > I am booted into it. snapper rollback says: > > Ambit is transactional. > Active snapshot is already default snapshot. > > snapper ls puts a star after the snapshot number. > > For some reason, this is the only snapshot that exists (a pre/post pair > made by zypper) after the one from the initial install (#0) . All > previous ones have been purged. > Maybe because you removed all the rest, as per your initial post?
> Sigh. I don't want to do a reinstall. All the software is set exactly as I want. It's one of (not the only) systems on which I develop software. Oh well. Time to extract all the needed information from it!
Why are you talking about this now? Andrei and I have been making suggestions of what you can try now, but all you have done is run commands Andrei suggested so we can get an idea what your system looks like right now. Doing a reinstall is the very last resort, and we are nowhere near there yet.
The suggestion was to try the rollback. I did that and reported that it did not succeed. Did I miss another suggestion that was not perhaps going to totally mess up the filesystem? I also want to be sure I have collected all useful information off the system before trying a possibly destructive command. I've not had a chance to do that yet. Day job and all that.
Andrei suggested "sudo snapper --ambit=classic rollback" and showed an example on his machine.
-- Cheers / Saludos,
Carlos E. R. (from 15.5 x86_64 at Telcontar)
-- Roger Oberholtzer
On 2024-03-19 03:10, Roger Oberholtzer wrote:
On Mon, Mar 18, 2024 at 5:43 PM Darryl Gregorash <raven@accesscomm.ca <mailto:raven@accesscomm.ca>> wrote:
Why are you talking about this now? Andrei and I have been making suggestions of what you can try now, but all you have done is run commands Andrei suggested so we can get an idea what your system looks like right now. Doing a reinstall is the very last resort, and we are nowhere near there yet.
The suggestion was to try the rollback. I did that and reported that it did not succeed. Did I miss another suggestion that was not perhaps going to totally mess up the filesystem? I also want to be sure I have collected all useful information off the system before trying a possibly destructive command. I've not had a chance to do that yet. Day job and all that.
Here is what you said in your first post:
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.
So the rollback did not succeed (I am quite amazed that it did not, assuming you did it correctly). We have no idea what procedure you used, or what causes you to say the rollback failed, because you saw fit not to report this to us. Next you say you deleted all the snapshots that were made later than the one you want as the default. If that rollback really did fail, then, I'm not certain, but this is possibly the very last thing you wanted to do at this stage. <snip>
I was thinking something similar. But I guess I cannot make 1405 (a zypper pre) the default and boot into that. And then rollback 1406. Would I need to rollback 1405?
Before resorting to this, try Andrei's suggestion. When he first posted it, he suggested "snapper rollback --ambit=classic", or something like that. The ambit option was in the wrong place (it certainly is a global option), so the command did not run. In his next post, he corrected this and showed the output from his system. So run snapper --ambit=classic rollback snapper list and let us see the output.
On Tue, Mar 19, 2024 at 6:37 PM Darryl Gregorash <raven@accesscomm.ca> wrote:
On 2024-03-19 03:10, Roger Oberholtzer wrote:
On Mon, Mar 18, 2024 at 5:43 PM Darryl Gregorash <raven@accesscomm.ca <mailto:raven@accesscomm.ca>> wrote:
Why are you talking about this now? Andrei and I have been making suggestions of what you can try now, but all you have done is run commands Andrei suggested so we can get an idea what your system looks like right now. Doing a reinstall is the very last resort, and we are nowhere near there yet.
The suggestion was to try the rollback. I did that and reported that it did not succeed. Did I miss another suggestion that was not perhaps going to totally mess up the filesystem? I also want to be sure I have collected all useful information off the system before trying a possibly destructive command. I've not had a chance to do that yet. Day job and all that.
Here is what you said in your first post:
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.
So the rollback did not succeed (I am quite amazed that it did not, assuming you did it correctly). We have no idea what procedure you used, or what causes you to say the rollback failed, because you saw fit not to report this to us.
I thought I had. I guess it got edited away. After the rollback, the SDDM login was still borked, complaining about missing kde/plasma 6 things. I cannot in any way see how that is possible if it had rolled back. So I thought I would just get rid of the update and try again.
Next you say you deleted all the snapshots that were made later than the one you want as the default. If that rollback really did fail, then, I'm not certain, but this is possibly the very last thing you wanted to do at this stage.
After I did the rollback and rebooted, and the kde6/plasma6 things remained, I decided to set the last good snapshot to the current one. Upon reflection, the thing to have done at that point is a rollback to that specific snapshot. Live and learn.
<snip>
I was thinking something similar. But I guess I cannot make 1405 (a zypper pre) the default and boot into that. And then rollback 1406. Would I need to rollback 1405?
Before resorting to this, try Andrei's suggestion. When he first posted it, he suggested "snapper rollback --ambit=classic", or something like that. The ambit option was in the wrong place (it certainly is a global option), so the command did not run. In his next post, he corrected this and showed the output from his system. So run snapper --ambit=classic rollback
I have reported exactly this elsewhere in this thread. (Spoiler alert: issue now solved). -- Roger Oberholtzer
On 2024-03-18 03:39, Roger Oberholtzer wrote:
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".
https://doc.opensuse.org/documentation/leap/archive/15.0/reference/html/book... If you did not choose "Bootable snapshots" when you booted the system, then you booted from the wrong menu item in the boot menu. Try booting from that menu now, then run (as root) "snapper rollback" and reboot normally. Hopefully, with your system in its current state, that will still work. If not, I have no idea what you can do. Since the snapshot you are now using is now the default, I'm not overly confident that this will work. If it does work, you should be booting with the root system mounted r/w. But if it does not, then possibly the only thing you can do is re-install the system (install, NOT upgrade) from a USB stick. Make sure to bookmark that URL above, for future reference.
On Mon, Mar 18, 2024 at 1:31 PM Darryl Gregorash <raven@accesscomm.ca> wrote:
On 2024-03-18 03:39, Roger Oberholtzer wrote:
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".
https://doc.opensuse.org/documentation/leap/archive/15.0/reference/html/book...
If you did not choose "Bootable snapshots" when you booted the system, then you booted from the wrong menu item in the boot menu. Try booting from that menu now, then run (as root) "snapper rollback" and reboot normally. Hopefully, with your system in its current state, that will still work. If not, I have no idea what you can do. Since the snapshot you are now using is now the default, I'm not overly confident that this will work. If it does work, you should be booting with the root system mounted r/w. But if it does not, then possibly the only thing you can do is re-install the system (install, NOT upgrade) from a USB stick. Make sure to bookmark that URL above, for future reference.
I booted from the main menu. I did not navigate anywhere like to Read-only snapshots. So I would have expected it to be writable as well. Odd that the system has gotten into a state where there are no writable options. snapper rollback just says: Ambit is transactional. Active snapshot is already default snapshot. Sigh. I don't want to do a reinstall. All the software is set exactly as I want. It's one of (not the only) systems on which I develop software. Oh well. Time to extract all the needed information from it! I still cannot believe that snapper cannot do whatever it does to allow changes. A new snapshot. Couldn't I make a snapshot via some other command than rollback? Or is it that since I'm in a snapshot, there is nothing to make a snapshot of and then allow new changes after that. If I wasn't booted into it perhaps? Like boot from a USB stick and then try the rollback on this filesystem? I suspect I'm just demonstrating my ignorance about that it the reason for the problem. -- Roger Oberholtzer
On 2024-03-18 13:49, Roger Oberholtzer wrote:
On Mon, Mar 18, 2024 at 1:31 PM Darryl Gregorash <raven@accesscomm.ca <>> wrote: On 2024-03-18 03:39, Roger Oberholtzer wrote:
I booted from the main menu. I did not navigate anywhere like to Read-only snapshots. So I would have expected it to be writable as well. Odd that the system has gotten into a state where there are no writable options. snapper rollback just says:
Ambit is transactional. Active snapshot is already default snapshot.
Sigh. I don't want to do a reinstall. All the software is set exactly as I want. It's one of (not the only) systems on which I develop software. Oh well. Time to extract all the needed information from it!
Andrei made a suggestion.
I still cannot believe that snapper cannot do whatever it does to allow changes. A new snapshot. Couldn't I make a snapshot via some other command than rollback? Or is it that since I'm in a snapshot, there is nothing to make a snapshot of and then allow new changes after that. If I wasn't booted into it perhaps? Like boot from a USB stick and then try the rollback on this filesystem? I suspect I'm just demonstrating my ignorance about that it the reason for the problem.
You are just demonstrating one of my reasons for not using btrfs :-) -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On Mon, Mar 18, 2024 at 2:12 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2024-03-18 13:49, Roger Oberholtzer wrote:
On Mon, Mar 18, 2024 at 1:31 PM Darryl Gregorash <raven@accesscomm.ca <>> wrote: On 2024-03-18 03:39, Roger Oberholtzer wrote:
I booted from the main menu. I did not navigate anywhere like to Read-only snapshots. So I would have expected it to be writable as well. Odd that the system has gotten into a state where there are no writable options. snapper rollback just says:
Ambit is transactional. Active snapshot is already default snapshot.
Sigh. I don't want to do a reinstall. All the software is set exactly as I want. It's one of (not the only) systems on which I develop software. Oh well. Time to extract all the needed information from it!
Andrei made a suggestion.
I think I have tried all the suggestions. The filesystem seems implacable. Everything is there and, as far as I can tell in a ro root filesystem, all seems to be working great. Sooo close. And yet soooo far.
I still cannot believe that snapper cannot do whatever it does to allow changes. A new snapshot. Couldn't I make a snapshot via some other command than rollback? Or is it that since I'm in a snapshot, there is nothing to make a snapshot of and then allow new changes after that. If I wasn't booted into it perhaps? Like boot from a USB stick and then try the rollback on this filesystem? I suspect I'm just demonstrating my ignorance about that it the reason for the problem.
You are just demonstrating one of my reasons for not using btrfs :-)
I have never had an issue before. I am sure that my rollback when I mistakenly thought that a zypper dup had mysteriously restarted the system and things looked very wrong are the cause of all this. I was hasty.
-- Cheers / Saludos,
Carlos E. R. (from 15.5 x86_64 at Telcontar)
-- Roger Oberholtzer
On 2024-03-18 15:49, Roger Oberholtzer wrote:
On Mon, Mar 18, 2024 at 2:12 PM Carlos E. R. <...>> wrote: On 2024-03-18 13:49, Roger Oberholtzer wrote: > On Mon, Mar 18, 2024 at 1:31 PM Darryl Gregorash <...> wrote: > On 2024-03-18 03:39, Roger Oberholtzer wrote:
> Sigh. I don't want to do a reinstall. All the software is set exactly as > I want. It's one of (not the only) systems on which I develop software. > Oh well. Time to extract all the needed information from it!
Andrei made a suggestion.
I think I have tried all the suggestions. The filesystem seems implacable. Everything is there and, as far as I can tell in a ro root filesystem, all seems to be working great. Sooo close. And yet soooo far.
Yes, you just posted now about what Andrei suggested.
> I still cannot believe that snapper cannot do whatever it does toallow > changes. A new snapshot. Couldn't I make a snapshot via some other > command than rollback? Or is it that since I'm in a snapshot, there is > nothing to make a snapshot of and then allow new changes after that. If > I wasn't booted into it perhaps? Like boot from a USB stick and then try > the rollback on this filesystem? I suspect I'm just demonstrating my > ignorance about that it the reason for the problem.
You are just demonstrating one of my reasons for not using btrfs :-)
I have never had an issue before. I am sure that my rollback when I mistakenly thought that a zypper dup had mysteriously restarted the system and things looked very wrong are the cause of all this. I was hasty.
Of course, rollback is a wonderful feature. I have known of many people, even novices, using it and saving the day. But if you are stuck, that's big trouble. Me, I know I don't understand btrfs. I know I can not repair its problems by myself. So, I don't use it, not for root. (I use it on external media I use for backup, because it is the only filesystem in Linux that I know of that has transparent compression r/w. And I add an encryption via LUKS.) -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 2024-03-18 07:12, Carlos E. R. wrote:
On 2024-03-18 13:49, Roger Oberholtzer wrote:
after that. If I wasn't booted into it perhaps? Like boot from a USB stick and then try the rollback on this filesystem? I suspect I'm just demonstrating my ignorance about that it the reason for the problem.
You are just demonstrating one of my reasons for not using btrfs :-)
Btrfs has nothing to do with this, except perhaps that Roger would not have got into this mess if he didn't have snapshots available. Of course, he could also have avoided it by first learning how to properly do a rollback.
Op maandag 18 maart 2024 18:11:47 CET schreef Darryl Gregorash:
Btrfs has nothing to do with this, except perhaps that Roger would not have got into this mess if he didn't have snapshots available.
Of course, he could also have avoided it by first learning how to properly do a rollback. I fully agree. The problem would not have existed if the sysadmin had not decided to remove the snapshots. Sorry Roger, but this is entirely a PEBKAC thing.
-- Gertjan Lettink a.k.a. Knurpht openSUSE Board openSUSE Forums Team
On Mon, Mar 18, 2024 at 6:24 PM Knurpht-openSUSE <knurpht@opensuse.org> wrote:
Op maandag 18 maart 2024 18:11:47 CET schreef Darryl Gregorash:
Btrfs has nothing to do with this, except perhaps that Roger would not have got into this mess if he didn't have snapshots available.
Of course, he could also have avoided it by first learning how to properly do a rollback. I fully agree. The problem would not have existed if the sysadmin had not decided to remove the snapshots. Sorry Roger, but this is entirely a PEBKAC thing.
Yeah. In hindsight (and after getting more information from others who had the kde6 zypper dup fail as mine did), I see that the rollback that I did was not needed. Still, why it exhibited the behavior I saw is not clear. -- Roger Oberholtzer
On Mon, Mar 18, 2024 at 6:13 PM Darryl Gregorash <raven@accesscomm.ca> wrote:
On 2024-03-18 07:12, Carlos E. R. wrote:
On 2024-03-18 13:49, Roger Oberholtzer wrote:
after that. If I wasn't booted into it perhaps? Like boot from a USB stick and then try the rollback on this filesystem? I suspect I'm just demonstrating my ignorance about that it the reason for the problem.
You are just demonstrating one of my reasons for not using btrfs :-)
Btrfs has nothing to do with this, except perhaps that Roger would not have got into this mess if he didn't have snapshots available.
Of course, he could also have avoided it by first learning how to properly do a rollback.
I did the rollback correctly. Or at least it did not complain. I have done this before when a zypper dup went astray. But when I rebooted, I still had odd stuff from the failed zypper dup. That I do not understand. I have never seen that before. -- Roger Oberholtzer
On 2024-03-19 10:13, Roger Oberholtzer wrote:
On Mon, Mar 18, 2024 at 6:13 PM Darryl Gregorash <...> wrote: On 2024-03-18 07:12, Carlos E. R. wrote: > On 2024-03-18 13:49, Roger Oberholtzer wrote: >> >> after that. If I wasn't booted into it perhaps? Like boot from a USB >> stick and then try the rollback on this filesystem? I suspect I'm just >> demonstrating my ignorance about that it the reason for the problem. > > You are just demonstrating one of my reasons for not using btrfs :-) > Btrfs has nothing to do with this, except perhaps that Roger would not have got into this mess if he didn't have snapshots available.
Of course, he could also have avoided it by first learning how to properly do a rollback.
I did the rollback correctly. Or at least it did not complain. I have done this before when a zypper dup went astray. But when I rebooted, I still had odd stuff from the failed zypper dup. That I do not understand. I have never seen that before.
Ah, the kde6 zypper dup. I heard that the desktop could crash during the procedure, halting the zypper process in its tracks and leaving a botched upgrade. The recommendation, a really old one that people has forgotten, is to run "zypper dup" in one of the virtual text consoles, not in graphic mode. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On Tue, Mar 19, 2024 at 2:26 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On Mon, Mar 18, 2024 at 6:13 PM Darryl Gregorash <...> wrote: On 2024-03-18 07:12, Carlos E. R. wrote: > On 2024-03-18 13:49, Roger Oberholtzer wrote: >> >> after that. If I wasn't booted into it perhaps? Like boot from a USB >> stick and then try the rollback on this filesystem? I suspect I'm just >> demonstrating my ignorance about that it the reason for the
On 2024-03-19 10:13, Roger Oberholtzer wrote: problem.
> > You are just demonstrating one of my reasons for not using btrfs
:-)
> Btrfs has nothing to do with this, except perhaps that Roger would
not
have got into this mess if he didn't have snapshots available.
Of course, he could also have avoided it by first learning how to properly do a rollback.
I did the rollback correctly. Or at least it did not complain. I have done this before when a zypper dup went astray. But when I rebooted, I still had odd stuff from the failed zypper dup. That I do not understand. I have never seen that before.
Ah, the kde6 zypper dup.
I heard that the desktop could crash during the procedure, halting the zypper process in its tracks and leaving a botched upgrade.
Exactly what happened. And that is how I interpreted what had happened. But it seems that what really happened was that the desktop service was restarted. And the KDE6 stuff was not complete. So one sat with a sddm that had complaints and would not let one log in. So I figured, do a rollback as it was an unsuccessful update. If I had instead popped to a virtual terminal and restarted the zypper dup, it would have finished and I would instead be asking about odd KDE6 quirks. The recommendation, a really old one that people has forgotten, is to
run "zypper dup" in one of the virtual text consoles, not in graphic mode.
Exactly. -- Roger Oberholtzer
On 3/19/24 09:25, Carlos E. R. wrote:
On 2024-03-19 10:13, Roger Oberholtzer wrote:
On Mon, Mar 18, 2024 at 6:13 PM Darryl Gregorash <...> wrote: On 2024-03-18 07:12, Carlos E. R. wrote: > On 2024-03-18 13:49, Roger Oberholtzer wrote: >> >> after that. If I wasn't booted into it perhaps? Like boot from a USB >> stick and then try the rollback on this filesystem? I suspect I'm just >> demonstrating my ignorance about that it the reason for the problem. > > You are just demonstrating one of my reasons for not using btrfs :-) > Btrfs has nothing to do with this, except perhaps that Roger would not have got into this mess if he didn't have snapshots available.
Of course, he could also have avoided it by first learning how to properly do a rollback.
I did the rollback correctly. Or at least it did not complain. I have done this before when a zypper dup went astray. But when I rebooted, I still had odd stuff from the failed zypper dup. That I do not understand. I have never seen that before.
Ah, the kde6 zypper dup.
I heard that the desktop could crash during the procedure, halting the zypper process in its tracks and leaving a botched upgrade.
The recommendation, a really old one that people has forgotten, is to run "zypper dup" in one of the virtual text consoles, not in graphic mode.
That's what happened to me (tumbleweed) so then booted to iceWM and then zypper dup'd and it worked....... mikeS
Top post here as it is the solution.. I once again have access to the computer. I have retried Andrei's suggestion: snapper --ambit=classic rollback It reported: .stingray:/home/roger # snapper --ambit=classic rollback Ambit is classic. Creating read-only snapshot of default subvolume. (Snapshot 1407.) Creating read-write snapshot of current subvolume. (Snapshot 1408.) Setting default subvolume to snapshot 1408. Client-side plugin '/usr/lib/snapper/plugins/10-sdbootutil.snapper' failed. Server-side plugin '/usr/lib/snapper/plugins/10-sdbootutil.snapper' failed. Server-side plugin '/usr/lib/snapper/plugins/10-sdbootutil.snapper' failed. stingray:/home/roger # snapper ls # | Type | Pre # | Date | User | Cleanup | Description | Userdata ------+--------+-------+---------------------------------+------+---------+--------------------------+-------------- 0 | single | | | root | | current | 1405 | pre | | Wed 13 Mar 2024 12:15:29 PM CET | root | number | zypp(zypper) | important=no 1406- | post | 1405 | Wed 13 Mar 2024 12:16:02 PM CET | root | number | | important=no 1407 | single | | Tue 19 Mar 2024 05:47:18 PM CET | root | number | rollback backup of #1406 | important=yes 1408+ | single | | Tue 19 Mar 2024 05:47:27 PM CET | root | | writable copy of #1406 | The three things that failed are not understood. I rebooted. And all seems good. I am where I was before the KDE6 adventure. Although I am convinced I tried the command with --ambit=classic both before rollback (global option) and after (rollback option), I see in my history that I only ran the command with it as a rollback option. It was a stressful Monday. Sigh. So, thanks all for the help. Especially Andrei who provided the solution. I am still confused why the snapshots before 1405/1406 went away. They were there at one point when I rebooted. After the reboot they were gone. I see in my command history that I did not even reference earlier snapshots. Maybe they were too old. I do a zypper dup every couple weeks. So they could not have been too old. It looks to me like the snapshot cleanup logic will remove older snapshots so one finds oneself in the situation I was in: only one snapshot - making it difficult to use that snapshot for anything. Especially not a rollback. Unless you know about the mystical --ambit=classic option. Anyway, I'm a happy camper. Once again, thanks all! On Tue, Mar 19, 2024 at 5:00 PM Michael Spartana <furryllama@comcast.net> wrote:
On 3/19/24 09:25, Carlos E. R. wrote:
On 2024-03-19 10:13, Roger Oberholtzer wrote:
On Mon, Mar 18, 2024 at 6:13 PM Darryl Gregorash <...> wrote: On 2024-03-18 07:12, Carlos E. R. wrote: > On 2024-03-18 13:49, Roger Oberholtzer wrote: >> >> after that. If I wasn't booted into it perhaps? Like boot from a USB >> stick and then try the rollback on this filesystem? I suspect I'm just >> demonstrating my ignorance about that it the reason for the problem. > > You are just demonstrating one of my reasons for not using btrfs :-) > Btrfs has nothing to do with this, except perhaps that Roger would not have got into this mess if he didn't have snapshots available.
Of course, he could also have avoided it by first learning how to properly do a rollback.
I did the rollback correctly. Or at least it did not complain. I have done this before when a zypper dup went astray. But when I rebooted, I still had odd stuff from the failed zypper dup. That I do not understand. I have never seen that before.
Ah, the kde6 zypper dup.
I heard that the desktop could crash during the procedure, halting the zypper process in its tracks and leaving a botched upgrade.
The recommendation, a really old one that people has forgotten, is to run "zypper dup" in one of the virtual text consoles, not in graphic mode.
That's what happened to me (tumbleweed) so then booted to iceWM and then zypper dup'd and it worked.......
mikeS
-- Roger Oberholtzer
On 2024-03-19 11:07, Roger Oberholtzer wrote:
Top post here as it is the solution..
I once again have access to the computer. I have retried Andrei's suggestion:
snapper --ambit=classic rollback
OK, you can ignore half of my earlier post now :D I'm glad this worked out for you.
I am still confused why the snapshots before 1405/1406 went away. They were there at one point when I rebooted. After the reboot they were
The only way those should have gone away by themselves is if snapper deleted them. You can find the rules for this (see man snapper-config): hadron:~ # snapper get-config Key | Value -----------------------+------ ALLOW_GROUPS | ALLOW_USERS | BACKGROUND_COMPARISON | yes EMPTY_PRE_POST_CLEANUP | yes EMPTY_PRE_POST_MIN_AGE | 1800 FREE_LIMIT | 0.2 FSTYPE | btrfs NUMBER_CLEANUP | yes NUMBER_LIMIT | 2-10 NUMBER_LIMIT_IMPORTANT | 4-10 NUMBER_MIN_AGE | 1800 QGROUP | 1/0 SPACE_LIMIT | 0.5 SUBVOLUME | / SYNC_ACL | no TIMELINE_CLEANUP | yes TIMELINE_CREATE | no TIMELINE_LIMIT_DAILY | 10 TIMELINE_LIMIT_HOURLY | 10 TIMELINE_LIMIT_MONTHLY | 10 TIMELINE_LIMIT_WEEKLY | 0 TIMELINE_LIMIT_YEARLY | 10 TIMELINE_MIN_AGE | 1800 The number limit settings are the important ones here. A minimum of 4, maximum of 10, important snapshots will be retained, and a minimum of 2, maximum of 10, others will also be retained. The two options are effected separately. Without seeing the results of snapper list before all this happened, it is impossible to know just what was deleted, and why. It seems that, when you removed snapshots, you deleted all the important ones. That leaves the unimportant ones; unless 1405/1406 were the only unimportant ones left, I would expect to be seeing more of them. Anyway, it's all water under the bridge now, and you seem to be back with a working system -- so just mark it down as one of life's greater mysteries, and carry on :D
in the situation I was in: only one snapshot - making it difficult to use that snapshot for anything. Especially not a rollback. Unless you know about the mystical --ambit=classic option.
There's an excellent (;) ) description of that option in the snapper manpage: -a, --ambit ambit Operate in the specified ambit. Can be used to override the ambit detection. Allowed ambits are auto, classic and transactional. Clearly just another example of why programmers should never be allowed to write software documentation :) Now, if you are feeling brave, log in on a text console (Ctrl-Alt-F1) and re-run zypper dup, as has been suggested. Personally, with all the information now available on this, if I were to do this I would drop into non-graphical most (init 3) before doing the dup, and switch back to graphical mode. But that's just me and my very cautious character. For example, it was years before I fully trusted the stability of drpm, zypper and btrfs. I'm not quite as bad as the Amish, though -- I do have a telephone, and I do drive a car :D
On Tue, Mar 19, 2024 at 7:15 PM Darryl Gregorash <raven@accesscomm.ca> wrote:
Now, if you are feeling brave, log in on a text console (Ctrl-Alt-F1) and re-run zypper dup, as has been suggested. Personally, with all the information now available on this, if I were to do this I would drop into non-graphical most (init 3) before doing the dup, and switch back to graphical mode. But that's just me and my very cautious character. For example, it was years before I fully trusted the stability of drpm, zypper and btrfs.
I have done the dup. And KDE6/plasma6 seem to be running fine. And I am leaving it in Wayland to see how that goes. -- Roger Oberholtzer
On Mon, Mar 18, 2024 at 3:50 PM Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
Couldn't I make a snapshot via some other command than rollback?
Yes, you can make btrfs snapshot. Read "man btrfs-subvolume". It will not be visible in the snapper interface until you add necessary metadata. It will not be visible in the grub boot menu until you recreate it (after having created snapper metadata). You will also need to manually make it the default subvolume. But if the goal is to just reboot into writable snapshot - you do not need snapper configuration, so "btrfs subvolume snapshot" + "btrfs subvolume set-default" will be enough. The final option is to simply change the current snapshot to read-write. There are many reasons why one should not do it, but if you are desperate - see "man btrfs-property".
On Mon, Mar 18, 2024 at 2:34 PM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Mon, Mar 18, 2024 at 3:50 PM Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
Couldn't I make a snapshot via some other command than rollback?
Yes, you can make btrfs snapshot. Read "man btrfs-subvolume". It will not be visible in the snapper interface until you add necessary metadata. It will not be visible in the grub boot menu until you recreate it (after having created snapper metadata). You will also need to manually make it the default subvolume.
But if the goal is to just reboot into writable snapshot - you do not need snapper configuration, so "btrfs subvolume snapshot" + "btrfs subvolume set-default" will be enough.
The final option is to simply change the current snapshot to read-write. There are many reasons why one should not do it, but if you are desperate - see "man btrfs-property".
If the only other option is a new install, perhaps it i worth a shot. I'll give it a day or so of exploring further and then decide... -- Roger Oberholtzer
participants (8)
-
Andrei Borzenkov -
Bill Swisher -
Carlos E. R. -
Darryl Gregorash -
James Knott -
Knurpht-openSUSE -
Michael Spartana -
Roger Oberholtzer