Corrupt SD partition table after unplugging USB?

[CharlesWGreenJr]

Hi,

I've had a pretty stable system for a number of weeks; using the delivered root filesystem I've put my '/usr' on an SD card, added swap, installed/built software including MythTV backend, and installed a couple of kernels.

Yesterday I installed a monolithic kernel including 'pvrusb2' driver to check out a USB tuner for MythTV.  Plugging in the tuner reported a couple of USB device lines in the kernel log, but no messages about loading firmware, etc.  So I decided to unplug it (couple more lines), and unplug the USB hub (which I've been using with no problems) to plug the tuner in directly.  I noticed several lines, including a couple about the flash (mmcblk0p1), thought "That's weird", plugged the USB tuner directly into the unit, saw the same two USB kernel log lines, and decided the USB hub wasn't interfering with the tuner getting its firmware via udev or whatever.

However, I've proceeded to continue to see more complaints about mmcblk0p1, tried rebooting, and e2fsck told me it couldn't make sense of the /usr filesystem.  What I've gathered from the following is that the partition table on the SD card may be corrupted; hope hope hope that if I simply re-'fdisk' it with the identical parameters I used to begin with, the /usr/ filesystem itself will still be there, else I guess I'll be restarting from near ground zero (perhaps this time putting the root filesystem on the new USB hard drive I just got).

Has anyone else experienced any relationship between unplugging USB devices and losing data on the SD card?  Any 'success stories' on easily recovering?  I've seen a few notes about flash corruption, both onboard and SD, but didn't notice any correlation with USB devices.  (I also had the serial console cable operational at the time, since I'd just had to change boot parameters for the new kernel, and I've seen references to that causing various types of instability, though again not flash corruption per se.)

Thanks,

Charles

Code:

* Checking file systems...
fsck 1.41.4 (27-Jan-2009)
fsck.ext3: No such file or directory while trying to open /dev/mmcblk0p1
/dev/mmcblk0p1:
The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

Seek to 1014479360:Invalid argument
dosfsck 3.0.1, 23 Nov 2008, FAT32, LFN
fsck died with exit status 9
   ...fail!
 * File system check failed.
A log is being saved in /var/log/fsck/checkfs if that location is writable.
Please repair the file system manually.
 * A maintenance shell will now be started.
CONTROL-D will terminate this shell and resume system boot.
Give root password for maintenance
(or type Control-D to continue):
Login incorrect.
Give root password for maintenance
(or type Control-D to continue):
bash: no job control in this shell
bash: groups: command not found
bash: dircolors: command not found
root@debian:~# fsck
fsck 1.41.4 (27-Jan-2009)
e2fsck 1.41.4 (27-Jan-2009)
fsck.ext3: No such file or directory while trying to open /dev/mmcblk0p1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

dosfsck 3.0.1, 23 Nov 2008, FAT32, LFN
Seek to 1014479360:Invalid argument
root@debian:~# e2fsck -b 8193 /dev/mmcblk0p1
e2fsck 1.41.4 (27-Jan-2009)
e2fsck: No such file or directory while trying to open /dev/mmcblk0p1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

[karurosu]

All I can think of is that you accidentally moved the SD and it was writing, but I still find it pretty odd.

[unpluggednomore]

Ouch.

Whenever I see the phrase "corrupt SD card partition table", alarm bells go off in my head.

Both the Openmoko and the OLPC XO-1 have been plagued with problems like this in the past.  Both are innovative hardware projects that were specifically designed for Linux.  Both were implemented without access to the vast armies of engineers and other resources that some companies can throw at problems.  Both succeeded in taming the SD card corruption bug after a year or more of effort, but only in a limited fashion.

Both projects now publish lists of SD cards that are believed to be compatible.  Using cards not listed there may still cause problems, even when using the latest patches.

I have a camera here that uses SD cards.  I can put any of my SD cards into it, and it will Just Work.  But if I put some of those cards into an XO-1 or an Openmoko, they may get corrupted.  (No, it's not an SD vs. SDHC problem, all of these devices are designed to work with SDHC.)  I'm not sure that anyone in the Linux world really knows how to make SD cards universally Just Work.

This doesn't seem to be related to the well-known Flash-cell-wearing-out problem.  The partition table is simply being wiped out.  Has something to do with suspend/resume apparently, but might be more complicated than that.  And it may relate to using Ext2/3 instead of FAT.

See:

http://dev.laptop.org/ticket/6532
http://docs.openmoko.org/trac/ticket/1802
http://docs.openmoko.org/trac/ticket/1743

It is not clear to me if the fixes used by these projects have propagated upstream to kernel.


I have also read reports of the Eee-PC running Linux having similar problems.

Of course it's entirely possible that the problem reported here has nothing to do with these other SD card bugs.