I've been experiencing a frustrating issue with my Kubuntu installation on a laptop that dual-boots with Windows 11. Sometimes, when I boot up, everything seems fine, but other times, the NVMe filesystem goes read-only and causes the system to crash gradually. When this happens, I often receive an 'Input/output error' when trying to execute any commands. Closing everything usually leads to a TTY screen where I'm confronted with repeated messages from the systemd journal failing to update due to the same 'Input/output error'. I can only use SysRq commands, but forcing a shutdown isn't ideal and affects the unsafe shutdown count.
This has happened multiple times in a row today. Previously, I dealt with kernel panics linked to split lock detection, which I thought I resolved by modifying the boot arguments. I suspect my current problem might be related but I'm unsure. I'm somewhat experienced with Linux, but not an expert, so I'm uncertain which logs to consult or how to interpret them for issues like NVIDIA driver problems, power management, or filesystem corruption. Right now, it seems stable after switching to a performance power plan, so I'm looking for guidance to troubleshoot this. Here are my specs:](embedded specs).
2 Answers
You seem to have a classic case of read-only filesystem issues, which can often stem from hardware or power management problems. When the system is on battery, it may throttle performance to save power, leading to errors in read/write operations. Given that you've experienced kernel panics and made changes to split lock detection, it's a good idea to reverse that change and monitor for instability. Also, keep an eye on your logs after enabling more detailed logging to spot any repeating errors that might correlate with the crashes.
It sounds like the SSD might be having issues too! The repeated I/O errors can indicate that the drive is failing or that there’s a problem with how it's interfacing with the system. Running a smartctl check is a great start, and you might want to consider looking into the health of the SSD using tools provided by your SSD manufacturer. Also, using a live USB to boot and see if the problem persists could help you determine if it's a software conflict or a hardware issue.
I did run a SMART check, and it passed. But I’ll definitely try booting from a live USB to rule out any software conflicts!
Makes sense! I'll check the logs more carefully once I revert those changes. It's worth a try!