Rootfs mounted R/O

Hello all
I recently Updated, Rebooted . and now rootfs is read only. Using thin LVM on an encrypted volume and nothing I have done seems to make it mount rw so I can get a workable system.

I have rolledback several versions via snapper
I have tried booting earlier kernel’s
I have attempted a btrfs check --clean on the /dev/mapper/system-root by running rescue and mounting the volumes manually.
I have plenty of space on all .

I can run rescue and via cryptsetup and vgchange get the filesystems mounted rw and everything looks fine.

Could someone please assist me in figuring out how to get back to good. I’d rather not re-install. and in fact that seems to be a PITA also becasue my original instll media now says “Installation system does not match boot medium” WTF… I just used it to install less than a month ago.

Please assist if possible.

Maybe a starting point could be to inspect the file permissions of your root, and maybe the next level mount points under root and compare with a working system.

ls -l *mountpoint *

The next thing I might suggest is to take a look at your root user account, whether anything has changed.

The bottom line though, is that what you’re seeing is probably an <expected> eventuality for any system that uses encrypted partitions, and you have to make sure you have a good and proven backup and recovery procedure. And so, unless you have an absolutely good reason to encrypt, you shouldn’t. (Good reasons might include regulatory compliance, highly sensitive data, data that can’t be secured any other way like a secure room).

The more I think about it, I would think that you can do a backup from your system (because it can be made readable) and restored to an unencrypted partition if you wanted to do so.

Lastly,
I haven’t tried it, but I wonder if a DVD Rescue might work… I’ve never tried in this type of situation where the root partition is encrypted and readable but not writable.

TSU

I didn’t think anything had changed significantly. I was in a running system and need to restart the system and on reboot this issue happened.

The bottom line though, is that what you’re seeing is probably an <expected> eventuality for any system that uses encrypted partitions, and you have to make sure you have a good and proven backup and recovery procedure. And so, unless you have an absolutely good reason to encrypt, you shouldn’t. (Good reasons might include regulatory compliance, highly sensitive data, data that can’t be secured any other way like a secure room).

This system is actually testing for another system that will be required to be encrypted for regulatory compliance so i’m trying to find the pitfalls. Its the whole reason I chose OpenSuse in the first place is the ability to run a fully encrypted system with BTRFS inside for the snapshot’ing. Although to be honest I’ll probably use LEAP for the production system .

The more I think about it, I would think that you can do a backup from your system (because it can be made readable) and restored to an unencrypted partition if you wanted to do so.

Yap. ended up backing everything up to a different encrypted part on another system after a rescue boot.

Lastly,
I haven’t tried it, but I wonder if a DVD Rescue might work… I’ve never tried in this type of situation where the root partition is encrypted and readable but not writable.

Almost exactly what I ended up doing, but not quite. I ended up re-installing Tumbleweed from a DVD/ usb stick with yesterday’s TW .iso. Then I assigned the partitions the during the installation procedure to be the exact same as before and did a “user copy” from the old system. Thankfully and really quite amazingly the TW install recognized that I had an encrypted Partition, then asked me for the password to it, decrypted and mounted everything so that all the LVM thin partitions were available when defining where to put everything during the re-install. And also amazingly (to me) it grabbed everything from the original user account and applied all the settings to the new one, so that once completely re-installed I booted into a KDE desktop that looked almost identical to the previous one. After that it was a simple matter of resetting some networking and a few zypper commands to re-install some of my basic tools but all in all not the worst bare-metal recovery I’ve ever had to do. All this onto my originally encrypted partition.

I have to give the Open Suse team huge props for this because honestly I thought I was in for a complete from scratch re-install but it really wasn’t that bad. I think however that probably a more stable codebase like LEAP wouldn’t have had this issue… at least I hope not. Any way alls well that ends well.

I want to thank you for your response to my post. It;s also a very nice thing to see a community that responds helpfully and appropriately,so thanks for that.

Mr Johnathan Bravo

Probably not the best idea to use TW a often changing cutting edge OS on a machine where you store encrypted important data with no backup :open_mouth:

as i said in my first response

This system is actually testing for another system that will be required to be encrypted for regulatory compliance so i’m trying to find the pitfalls. Its the whole reason I chose OpenSuse in the first place is the ability to run a fully encrypted system with BTRFS inside for the snapshot’ing. Although to be honest I’ll probably use LEAP for the production system .

But thanks for the helpful advice anyway :wink:

Mr Johnathan Bravo

There is a problem to auto-assemble thin volumes. Fix is submitted and eventually will appear in TW. You could try force load dm-thin using modules.load.d to see if it helps. See 983221 – system fails to load dm-* modules after kernel/lvm2 updates

since you have not mentioned scrub, there is a guide here on btrfs recovery https://en.opensuse.org/SDB:BTRFS
**