I found this error when using Ubuntu 16.04.1. It also occurs on Ubuntu 12.04.5, 14.04.5, 16.04.3, debian 9.1.0, and apparently any version of the kernel after 3.1.10.

The error occurs when I put the OS on a compact flash, plug the CF into a card reader that supports both USB 2.0 and 3.0, and plug the card into the USB2.0 port of a PC. During or after it boots the error will occur and make the entire system read-only. It sometimes occurs during boot; usually occurs within a few minutes to a few hours after boot; sometimes takes 24ish hours to occur; and once took 48ish hours to occur. I know as soon as it occurs because the terminal (since I am using the server version I don't have a GUI) will suddenly display the error. When the error occurs after boot it is as follows:

blk_update_request: I/O error, dev sda, sector 2624440[this number can change]
Buffer I/O error on device sda1, logical block 275975[this number can change]
Aborting journal on device sda1-8
JBD2: Error -5 detected when updating journal superblock for sda1-8.
EXT4-fs error (device sda1): ext4_reserve_inode_write:5146: Journal has aborted
EXT4-fs (sda1): Remounting filesystem read-only

The first two lines may repeat several times before the others appear. This is variable.

If the system goes read-only before the boot can even finish I see the following error after logging in:

Unable to setup logging. [Errno 30] Read-only file system: 
run-parts: /etc/update-motd.d/50-landscape-sysinfo exited with return code 1
/usr/lib/update-notifier/update-motd-fsck-at-reboot: 33: /usr/lib/update-notifier/update-motd
oot: Read-only file system

In journalctl I see the following:

usb 1-1: reset high-speed USB device number 2 using ehci-pci
sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd 0:0:0:0: [sda] tag#0 Sense Key : Unit Attention [current]
sd 0:0:0:0: [sda] tag#0 Add. Sense: Not ready to ready change, medium may have changed
sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 00 28 0b e8 00 00 10 00
blk_update_request: I/O error, dev sda, sector 2624440[this number can change]
Aborting journal on device sda1-8.
EXT4-fs error (device sda1): ext4_journal_check_start:56: Detected aborted journal
EXT4-fs (sda1): Remounting filesystem read-only
EXT4-fs (sda1): ext4_writepages: jdb2_start: 6144 pages, ino 34333; err -30

Rebooting will cause the system to become rw again but inevitably the error will occur and it will become read-only again.

Running on the USB3.0 port does not produce the error. Running with a card reader that only supports USB2.0 does not produce the error.

The card readers that have produced the error: Transcend TS-RDF8K, Delkin DDREADER-42, Kingston FCR-HS3 and FCR-HS4, Lexar LRW400CRBNA. The cards that have produced the error: Kingston 4GB, Transcend CF170. The platforms that have produced the error: (1.2GHz VIA Eden X4 quad-core processor + VIA VX11H MSP), (VIA EPIA-P820 + EPIA-P720 Pic-ITZ boards), (GA-H170-HD3 + Intel Core i7-6700K 4.0GHz + super micro X7SPE-HF-D525)

This occurs with both brand new and slightly used hardware. It occurs with Ubuntu/Debian freshly installed and after edited for my own purposes. It occurs both with putting a vhd on the CF and with installing the OS directly to the CF card.

There does not appear to be any specific event that occurs before the error except for the USB reset shown in journalctl.

I do not believe it to be a purely hardware issue, but rather a hardware + kernel issue since A: all of the above hardware works with kernel 3.1.10 and earlier B: I have used multiple cards/card readers/platforms of each type (and from different batches) incase one was malfunctioning

I have been using Ubuntu 11.04 with kernel 2.6.38-8-generic-pae for years with no problem.

Unfortunately I do not know specifically what is causing this, only under what circumstances it occurs. I have been told that it is a bug in the kernel, but I would like to ask here one last time before I decide to report it.

  • 1
    Wow, it's a lot of research. Yes, you shall definitely report a bug! If you're willing, you could try bisecting to find which one commit caused the problem, and then report with keywords [BISECTED] [REGRESSION], it gonna draw more attention. – Hi-Angel Aug 31 '17 at 21:19
  • Oh, and if you find the problem commit, you can also add to CC of the bugreport the author of the problem commit. – Hi-Angel Aug 31 '17 at 21:30
  • 1
    I've been working on and off on this since last December, I've tried pretty much everything I could think of. Bisecting is a good idea, thank you. – khm Sep 1 '17 at 11:55
  • FTR, the simple fact that it is working in prev. kernel version but not in the newest is enough to report a bug. I imagine it could be that the hw violating some protocol. There's a bunch of crappy hw IRL. In such cases kernel devs often comes up with a workaround. And please, if you get the commit bisected, go report it upstream, not downstream (e.g. not to launchpad). – Hi-Angel Sep 1 '17 at 14:29
  • I am so far unable to bisect because of problems with git. I was going to report this on bugzilla.kernel.org either way. They seemed to be the appropriate place to report this. – khm Sep 1 '17 at 15:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.