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.
The reason might be corrupted filesystem, which does not allow proper mounting of partitions according to fstab. Then Linux will boot to a very curtailed state.
Especially this applies to filesystems that are shared (used by both) between Windows and Linux.
Run the usual chkdsk command after booting into Windows. Reboot into Windows and run the chkdsk command again.
If this does not help, reduce to minimum the partitions being mounting according to fstab. Then mount the remaining ones manually, one by one.
That is of course all very true, and that is why we wait for the OP’s report about what happens during booting so we can hopefully advise more precise actions.
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?
A partition is used by Windows and Linux in the same computer, for exchange of files.
Windows crashes or is shut down forcefully. This leaves the filesystem in dirty state.
Linux, when booted, cannot mount that partition, or mounts read-only. There are no tools in Linux to repair NTFS partitions.
Windows, on the other hand, has repairing capability. Booting into Windows and repairing resolves the problem. So does temporarily excluding the offending partition from fstab, if possible.
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
.
Your trouble is with Tumbleweed. Tinkering with Windows won’t help much. Troubleshooting is much easier when using a working system. Boot into a Tumbleweed rescue or live system.
mount the troubled device: mount /dev/sda6 /mnt/
post the complete and unaltered output of the mount command
post the output of: btrfs filesystem usage -T /mnt/