Recently I ran into an issue with my Raspberry Pi. It was not accessible over the network and the HDMI output showed no signal, too. The power LED on the RPi was lit, however the green LED showing SD card activity was not blinking when power was attached.
On my RPi I was running the Debian varian Raspian however it failed to boot. So I fired up a Debian PC and looked into the SD card. On the SD card there are two partitions as shown by
Disk /dev/sdg: 15.8 GB, 15811476992 bytes 64 heads, 32 sectors/track, 15078 cylinders, total 30881791 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: 0x000c7b31 Device Boot Start End Blocks Id System /dev/sdg1 8192 122879 57344 c W95 FAT32 (LBA) /dev/sdg2 122880 30881791 15379456 83 Linux
First, a small 8 MB FAT32 partition which stores the bootloader and the kernel image and then a larger ext4 partition which is expanded on installation to fill up the remaining space on the SD card (mine was 16 GB large).
Fine, so let us try to mount the second partition to recover some data:
mount -t ext4 -o ro /dev/sdg2 /media/sd but without luck, this was the output:
mount: wrong fs type, bad option, bad superblock on /dev/sdg2, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so
I did was I was told to do and checked the kernel logs using
dmesg | tail. The last entry showed something interesting:
[ 707.493811] EXT4-fs (sdg2): bad geometry: block count 3844864 exceeds size of device (3844863 blocks)
Hmm, something is wrong with the partition, so let us run good old
fsck /dev/sdg2 but this rose an error, too:
fsck from util-linux 2.20.1 e2fsck 1.42.5 (29-Jul-2012) /dev/sdg2: recovering journal The filesystem size (according to the superblock) is 3844864 blocks The physical size of the device is 3844863 blocks Either the superblock or the partition table is likely to be corrupt! Abort? yes
So the partition is corrupt, or at least the super block as it reports the wrong size. So maybe we can resize the partition instead using
resize2fs /dev/sdg2 which gave the promising output:
resize2fs 1.42.5 (29-Jul-2012) Resizing the filesystem on /dev/sdg2 to 3844863 (4k) blocks. The filesystem on /dev/sdg2 is now 3844863 blocks long.
After this I was able to mount the partition using
mount -o ro /dev/sdg2 /media/sd. I unmounted it and reran
fsck /dev/sdg2 on it which found some orphaned nodes and repaired it. I could then reinsert the card into my RPi and it booted and worked!
Please note: Your milage may vary as it cannot be made sure that data integrity is still OK. This would be possible with checksummed file systems like ZFS or buttrfs. It is always a good idea to have a backup.