I took a laptop to a meeting and booted normally. It logged into the available wifi. I had to step out of the meeting for a few minutes and closed the lid on the laptop. Upon return, it appeared normal but had dropped the wifi and could see no available wife signals even though I know there were many. At the end of the meeting, I shut it down and came home.
I tried to reboot with a wired connection so I could update the broadcom driver, assuming that was the problem. But the laptop will not boot properly. It boots to a read-only file system with no gui. I can log in as user or root but cannot start yast. Zypper dup fails with the read-only system message. Even as I try this, I get endless messages saying its trying to write journal entries but can’t to a read-only system. I have tried all the recovery boot options listed in the grub menu (the graphical one works at reboot) but none get me to the normal boot. This is a dual boot laptop with Windows 10. It continues to boot normally to Windows.
Is there a command I can use to make the system “writeable?” Or is it just a re-install?
I assume you first have to find out why, apparently the root file system, is mounted read-only before you can even think about repairing. After all you can not repair when you do not know what to repair.
During boot hit Esc so you can see what happens. Look in the logs.
I second hcvv request. First thing to do is diagnose what’s going on, and have in mind that a read-only file system is different than a broken/unmountable filesystem that needs structural repair.
You can begin troubleshooting by running dmesg just after
Does it keep putting root fs in read-only mode after reboots?
Find the context where FS is made RO: Run “dmesg | grep -C 10 btrfs”. You can paste output here. You should be able to use susepaste from your system.
Do you have plenty of space to spare? Run “sudo btrfs filesystem usage /”
There are other things you can do, but first we need information for work with. Since it’s TW you should have a fairly updated kernel but if you prefer you can use a recovery disk, but probably not needed yet.
I have run each suggestion. I don’t know how to capture the output of the linux commands, so I took pictures of the output with my cell phone. I can try to post those. In the meantime, I booted windows twice and ran chkdsk in each reboot. The results were identical and I can post a text file of the output, but the result is that “Windows has scanned the file system and found no problems . No further action is required.”
When I boot into TW, running the btrfs commands shows only one error:
BTRFS: error (device sda6) in btrfs_run_delayed_refs:2124: error=-5 IO failure
BTRFS: info (device sda6): forced readonly
BTRFS: info (device sda6): balance: ended with status: -30
I’m typing this from a photo of the screen, but its accurate.
When I run the other btrfs command, the process stalls with these lines:
Reached target Remote File Systems
Starting Permit User Sessions
Finished Permit user Sessions
Starting X Display Manager
Starting Hold until boot process finishes up
Starting Locale Service
Started Locale Service
Then it stalls.
Finally, the btrfs usage command shows I have 16GB free.
Your Linux system has a read-only file system (probably the root file system). We are trying to find out what the system says during a boot.
Apparently you have also an MS Windows operating system on the system and you say that there is no problem there. Then why are you running file system repair programs on that Windows system trying to repair the Windows file systems were there are no problems? Can’t we concentrate on the real problem that openSUSE has?
Based on a partial dmesg output, most likely a balance operation was running when system was shutdown. On restart it attempted to resume this balance operation and failed. There’s no enough information on that but maybe lack of free space.
First link (and second is the same) point to the same evidence as OP here. And everyone there pointed at a completely wrong direction. In TW, any other fs means more work when it breaks.
Last link is unrelated.
That was a good call.
The read-only partition is btrfs, Windows can’t cause a problem there. NTFS is unrelated here.
Based on evidence this is the proper resolution.
Here’s the commands again:
mount -o remount,rw,skip_balance /
btrfs balance cancel /
In case remount fails because it was mounted read-only with error, you’ll have to use a recovery disk, and mount this fs somewhere (e.g. /mnt/root) and replace / with the new path in both commands.
This is clearly not the case here. The problem is about a read-only root file system. All his symptoms are about being unable to write anything to files on the root file system (like logging, zypper, etc.) never about trying to write something to a maybe, or maybe not mounted non-Linuxdata file system somewhere down the directory tree