SSD going read only causing errors while updates & upgrading to 26.04

Support and Help
, ,
1

Ubuntu Support Template

Ubuntu Version:Upgrade 25.10 to 26.04

Problem Description:
SSD is becoming unstable in use and during update and upgrade requests.

First observed midway into 26.04 clean install and causing “something went wrong” message.

Repeated 25.10 without using net or optional package install was able to get a bootable system.

After repeated incremental steps between reboots now updates are pending but summarized.

sudo apt update will succeed a time or two before demonstrating a read only failure.

unattended-upgrade has been removed to avoid invisible read only messages.

Also used touch command to see success than later failure.

Example:

sudo apt update initially then eventually fails and displays this message about being read only

$ sudo apt update
Hit:3 http://us.archive.ubuntu.com/ubuntu questing InRelease
Hit:4 http://us.archive.ubuntu.com/ubuntu questing-updates InRelease
Hit:5 http://us.archive.ubuntu.com/ubuntu questing-backports InRelease
Hit:6 http://security.ubuntu.com/ubuntu questing-security InRelease
Warning: chown to _apt:root of directory /var/lib/apt/lists/partial failed - SetupAPTPartialDirectory (30: Read-only file system)

Screenshots or Error Messages:

Can’t upload screen shot for some reason and no way to attach files found either.

Simultaneously I was in a terminal session and ssh to another to cut and paste cli in text file (nano)

$ uptime
14:14:04 up 1 min, 1 user, load average: 1.51, 0.40, 0.14
$ touch ME
$ touch ME ← started the above update request
$ touch ME
touch: cannot touch ‘ME’: Read-only file system
$ uptime
14:25:25 up 6 min, 1 user, load average: 0.72, 0.49, 0.22
$ date
Sat Jun 20 14:26:25 EDT 2026
$ ls -lh ME
-rw-rw-r-- 1 1000 1000 0 Jun 20 14:23 ME

What I’ve Tried:

This is from the USB used previously on same system successfully.
It was running daily without errors.

In an attempting to clean install 26.04 a read only error occurred
and incorrectly assumed the 26.04 was at fault.

Later a log screen was captured and the /var/log moved to USB writable space

I have tried numerous USB ISO images and settled on 25.10 install without using internet during
install which reduces time and still fails but getting far enough to make internal drive bootable.
Now system can be booted and some stuff done before read only state occurs.
I removed unattended-upgrade package to avoid locking package operations to complete before read only occurs.
Also boot directly without login password to admin account with sudoers setup.

This SSD experience is new to me and am hoping for some encouraging help with a fix.

1 Like
2

You indicate you had an error when trying to do a clean install of 26.04. At what specific point of the installation happen? You then indicate you did a ‘successful’ install of 25.10 and it boots so are you now trying to update/upgrade to 26.04 from 25.10.

I’m not sure what the purpose of the ‘touch ME’ command was? If you are getting a read-only error on an installed system the first thing to do is to run a filesystem check with fsck so have you done that?

2 Likes
3

As above.

I suspect you have an about to fail SSD, possibly a bad “burn” of the live/installation media or both.

1 Like
4

(Please put such output in pre-formatted CODE blocks; click </> on an empty line and paste into the new element.)

Check what happens when you follow the log:

journalctl -f

If that is too much output, reduce it by just focusing on high priority messages, like err or warning.

journalctl -f -p err

If that shows I/O Error or similar, do as @ogra suggested in the other topic.

If everything seems to checkout, you should rescue what hold dear from that device and replace it. Also, see that other link I posted in the adjacent topic:
https://cr0x.net/en/debian-read-only-filesystem-recovery/

I have since read it to the end and it’s the real deal; someone with experience showing the way to debug such an issue. Don’t bother with dmesg, though; it’s all in the journal, hence journalctl shows those kernel messages too; it can even be limited to those:

journalctl --dmesg
2 Likes
5

For all intended purposes/usages they’re EXACTLY like the old HDDs.

Different technologies, way better performance and now also better longevity (but they fail like any other), but from the user’s and the OS’ point of view exactly the same.

1 Like
7

Don’t try to appease the “storage gods” by that kind of song and dance; it’s almost like mocking the corpse to be. :wink:

With modern SSD’s and their wear leveling and spare areas, there is no such thing as an isolated area; the controller silently shifts data around as it sees fit. When you see failures at that scale, and I am pretty sure you will, once you stop guessing and start looking, as described in that article above, it is time to cut your losses and save what’s dear to you in terms of data.

That’s also a hard no on:

Can I create a partition to isolate use of that space after doing a surface test ?

We are also not storage specialists here, so those questions a just about getting out of scope of this forum.

1 Like
9

That’s a pretty contrived way of doing it; again:

journalctl -f

will tell you exactly what happens when in realtime; with colors even for warnings (yellow) and errors (red).

To reiterate, less guessing, more looking at actual data; it’s all there.

2 Likes
10

A few months ago, I had a similar error when Ubuntu 24.04 switched from kernel 6.14 to 6.17 on my old Intel i5 4690 computer from 2014. I don’t know if this is your hardware, but for me, it was enough to disable this option in the BIOS: Intel Virtualization Technology for Directed I/O (or VT-d)

1 Like
11

The fsck software will note/mark bad blocks on the physical drive so there will be no attempt by the system to use them in the future. It does not mark specific ‘files’ and doesn’t actually repair anything on the drive as it is not possible to repair physical hardware with software. More details at the link below and any number of other sites online.

https://askubuntu.com/questions/241944/how-to-fix-the-hard-drive-bad-sector

Trying fsck is just one possibility to resolve your problem which may be something else.

1 Like
12

Can journal log to read only drive which is what I am experiencing ?

1 Like
14

Good point; from my understanding journald should work, at least to a certain extent, because it writes to a buffer and syncs that regularly to persistent storage. One can also configure it to use volatile storage but that suffers from the chicken and egg problem that you’d need to write its config file to a possibly read-only filesystem.
But there is a way around that; mount a tmpfs on the directory containing its config drop-ins:

sudo mkdir -p /etc/systemd/journald.conf.d/
sudo mount -t tmpfs /etc/systemd/journald.conf.d/

(or use an overlayfs)

And then just put a config snippet there that has this in it:

[Journal]
Storage=volatile

(must be named with the .conf suffix`)

This script snippet does just that:

sudo tee /etc/systemd/journald.conf.d/zz-volatile.conf >/dev/null <<EOF
[Journal]
Storage=volatile
EOF

Restart the journal:

sudo systemctl reload-or-restart systemd-journald

Another way would be to fool the journal service into thinking it is writing to persistent storage by just mounting a tmpfs or and overlayfs on /var/log/journal.

If you want to keep those logs, you can also just mount some external storage on /var/log.

15

Maybe, just maybe, there is another possibility. I found this while searching for failure modes of journald when trying to write to read-only storage:

But you didn’t say if yours is an NVMe. From the question about AHCI I just assumed it’s a SATA device, for which that parameter will do nothing.

1 Like
17

If that’s in reference to getting writable persistent storage for the logs, yes; as I said:

If you want to keep those logs, you can also just mount some external storage on /var/log.

In the meantime it came to me that, in this particular instance, dmesg -w might actually be the better choice because it just reads the volatile ring buffer. But I don’t know how journald will behave when it fails to write to a read-only destination; it might just stop feeding that buffer as well. I guess you’ll find out. :wink:

1 Like
18

(post deleted by author)

1 Like
19

You will really need to provide some logs, else all attempts to help will just be random guesswork and just a waste of your (and our) time in the end …

Just run:

sudo dmesg | nc termbin.com 9999

And paste the URL this prints here, that will show us your kernel log and all its errors

(for the journal you should be able to simply replace sudo dmesg with journalctl in the above command (no need for sudo in this one) and paste that here too)

The kernel normally tells you in these logs why exactly it thought your disk needs re-mounting in readonly mode …

(FWIW, journald always logs to a ringbuffer in RAM, even if it can not flush the log to disk so you should be able to get all we need (older messages will be cut off but if you run the command not too shortly after the system went read-only all relevant info should be there))

3 Likes
20

I only want to add that the journal should be limited to the current boot by using the -b switch of journalctl (or --since perhaps; -b is usually enough, though), otherwise it can be very looong.

2 Likes
22

I really doubt that it fixed the underlying issue. It’s unfortunate that you took that particular way out too[1]. When I/O errors happen at scale on writes[2] it’s a clear sign that the SSD cells are way past their prime.

Have you ever looked at the journal, actually? We’ve tried to guide you on how to diagnose this, but you seem to have made up your mind on pure conjecture.

I actually held off on suggesting to check the S.M.A.R.T. log, because I considered it too much, given the apparent difficulties you seemed to have with the other stuff asked of you. Maybe that was a mistake. :man_shrugging:

  1. by no means a dig at Debian, but reinstalling at the first sign of trouble never was an actual solution ↩︎

  2. given your information, it was unattended-upgrades trying to write to the device, which sent it over the edge ↩︎

1 Like
24

You may not realize it just yet, but your goal is our goal as well.[1]

sudo smartctl -x /path/to/your/ssd_device

  1. The “workaround” is a thick layer of paint over the rust that’s eating away at your machine, as it seems. :wink: ↩︎

1 Like
26

Paste its contents here in a pre-formatted text (code) block; click </> on an empty line first, then paste. Or use a pastebin site and post the link.

1 Like
30

https://termbin.com/skep

Also copied text from installer and files from /var/log/installer

1 Like