Partition table not recognized by Linux kernel

Question

I experience relatively often that the partition table of a USB stick or SD card is suddenly no longer recognized by the kernel while (g)parted and fdisk still see it, as do other systems. I can even instruct gparted to do a fsck on one of the partitions but it fails of course because the device files let's say /dev/sdbX don't exist.

I'll attach the dmesg output:

[ 8771.136129] usb 1-5: new high-speed USB device number 4 using ehci_hcd
[ 8771.330322] Initializing USB Mass Storage driver...
[ 8771.330766] scsi4 : usb-storage 1-5:1.0
[ 8771.331108] usbcore: registered new interface driver usb-storage
[ 8771.331118] USB Mass Storage support registered.
[ 8772.329734] scsi 4:0:0:0: Direct-Access     Generic  STORAGE DEVICE   0207 PQ: 0 ANSI: 0
[ 8772.334359] sd 4:0:0:0: Attached scsi generic sg1 type 0
[ 8772.619619] sd 4:0:0:0: [sdb] 31586304 512-byte logical blocks: (16.1 GB/15.0 GiB)
[ 8772.620955] sd 4:0:0:0: [sdb] Write Protect is off
[ 8772.620971] sd 4:0:0:0: [sdb] Mode Sense: 0b 00 00 08
[ 8772.622303] sd 4:0:0:0: [sdb] No Caching mode page present
[ 8772.622317] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[ 8772.629970] sd 4:0:0:0: [sdb] No Caching mode page present
[ 8772.629992] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[ 8775.030231] sd 4:0:0:0: [sdb] Unhandled sense code
[ 8775.030240] sd 4:0:0:0: [sdb]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 8775.030249] sd 4:0:0:0: [sdb]  Sense Key : Medium Error [current] 
[ 8775.030259] sd 4:0:0:0: [sdb]  Add. Sense: Data phase CRC error detected
[ 8775.030271] sd 4:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00
[ 8775.030291] end_request: I/O error, dev sdb, sector 0
[ 8775.030300] quiet_error: 30 callbacks suppressed
[ 8775.030306] Buffer I/O error on device sdb, logical block 0
[ 8775.033781] ldm_validate_partition_table(): Disk read failed.
[ 8775.033813] Dev sdb: unable to read RDB block 0
[ 8775.037147]  sdb: unable to read partition table
[ 8775.047170] sd 4:0:0:0: [sdb] No Caching mode page present
[ 8775.047185] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[ 8775.047196] sd 4:0:0:0: [sdb] Attached SCSI removable disk

Here, on the other hand, is what parted has to say about the same disk, at the same time:

(parted) print                                                            
Model: Generic STORAGE DEVICE (scsi)
Disk /dev/sdb: 16.2GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
 1      4194kB  62.9MB  58.7MB  primary  fat16        lba
 2      62.9MB  16.2GB  16.1GB  primary  ext4

It's not only parted, even the older fdisk has no trouble with that partition table:

Command (m for help): p

Disk /dev/sdb: 16.2 GB, 16172187648 bytes
64 heads, 32 sectors/track, 15423 cylinders, total 31586304 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000dbfc6

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            8192      122879       57344    c  W95 FAT32 (LBA)
/dev/sdb2          122880    31586303    15731712   83  Linux

I'm really clueless. It would be easy to say the partition table is corrupted but then why can gparted still read it without complaints (and there are none) or how can I reconstruct the partition table from what (g)parted miraculously found out?

Solution 1

For some reason your kernel fails to read the partition table:

[ 8775.030291] end_request: I/O error, dev sdb, sector 0
[ 8775.030300] quiet_error: 30 callbacks suppressed
[ 8775.030306] Buffer I/O error on device sdb, logical block 0
[ 8775.033781] ldm_validate_partition_table(): Disk read failed.

Thus, it can't create devices for partitions as it did not read the partition table. Later when you try to see the partition table with parted or fdisk the IO is performed successfully.

Try to use partprobe /dev/sdX when your kernel did not recognized the partitions at boot time.

man partprobe:

PARTPROBE(8)                                                         GNU Parted Manual                                                        PARTPROBE(8)

NAME
       partprobe - inform the OS of partition table changes

SYNOPSIS
       partprobe [-d] [-s] [devices...]

DESCRIPTION
       This manual page documents briefly the partprobe command.

       partprobe  is  a  program  that informs the operating system kernel of partition table changes, by requesting that the operating system re-read the
       partition table.

Solution 2

This might have been the case for you, and just in case anyone else runs into this problem, I had this problem before and found that having gparted or another partition editor can block the partition table reading. Close gparted and try again, it might be as simple as that.

Comments

[Christian]

That actually solves the problem. I'm going to see if it solves it permanently for this particular medium. If not, do you have any ideas how to tell the kernel to automatically recheck automatically? If I'd be forced to guess I'd say the problem is with device that are hot-plugged being read before they are really ready. Any alternative theory?

[Serge]

No, it will not solve the problem permanently. It just tell the kernel to re-read partition table. The alternative theory is some hw failure - either your usb port is close to be broken or the device itself. Or the thing is much simple: there is a bad contact in the usb port.

[Christian]

You're right, it doesn't fix it permanently for this device and this problem also occurs when the SD card is already present during boot. This happens very reproducibly so a faulty contact is probably not the culprit. The partition table can only not be read initially. I never ever have any problem with parted, fdisk or now partprobe. So that's a very weird hardware failure then. Maybe I should write a script that listens to dbus and automatically triggers rereading the partition table but if that stupid workaround really fixes the issue, I'd call it a kernel bug after all.

[Christian]

It's hard to test. I should have kept record of all the devices that had this problem. All I can say that indeed the same SD card works without problems when connected to an USB port with an adapter. What I meant with "kernel bug" is that the kernel should adapt to different hardware and if there is some timing issue with whatever controller then this should be taken into account.