I find it a bit bemusing that I’d find myself fixing one of my several Raspberry Pi’s today, on National Pi Day. I can say that I was hoping that instead of making repairs to the filesystem I’d be playing with my new Pi3. Alas, ordering from the UK apparently involves carrier pigions and over 10 days later I’m still waiting.
So I noticed that I wasn’t able to connect to my “son’s” Pi. The original intent when I purchased it was to turn it into an inexpensive school computer. Hey, he’s only 10, it’s not like he needs insane computing power. Anyway, that never came to fruition so instead it’s my IRC gateway. Rather than running irssi locally on each computer I just run it via screen so I can detach the session when I’m done and ssh to the gateway from whichever device I happen to be on.
I connected a monitor and there was no signal. I toggled the power and it stopped during the boot process and complained about a kernel panic and being able to mount the device. Well, the last thing I want is a panicked Pi so I tried what any reasonable desert lover would do. I took some jumper wires and tried grounding GPIO pins 1 and GND. That made the Pi reboot but not into recovery mode. Neither did holding the shift key. Then I tried jumping pins 5 and 6. That didn’t seem to have any effect at all. I guess none of that works because I didn’t actually use NOOBS.
With none of that working it was time to break out the command line. I put the microSD card in an adapter and inserted it into the Fedora laptop I’m writing this one. The device mounted and I could read it but it obviously wasn’t bootable anymore.
A quick execution of fsck gave me the device info I was looking for.
# sudo fsck -l Device Boot Start End Sectors Size Id Type /dev/mmcblk0p1 8192 122879 114688 56M c W95 FAT32 (LBA) /dev/mmcblk0p2 122880 31291391 31168512 14.9G 83 Linux
I unmounted the devices and tried running fsck on the Linux partion but that didn’t work so well.
#sudo fsck -Va /dev/mmcblk0p2 Bad magic number in super-block while trying to open /dev/mmcblk0p2 The superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem. If the device is valid and it really contains an ext2/ext3/ext4 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> or e2fsck -b 32768 <device>
So tI followed it’s advice. 🙂
# sudo e2fsck -b 32768 /dev/mmcblk0p2 e2fsck 1.42.13 (17-May-2015) /dev/mmcblk0p2: recovering journal e2fsck: unable to set superblock flags on /dev/mmcblk0p2 /dev/mmcblk0p2: ***** FILE SYSTEM WAS MODIFIED ***** /dev/mmcblk0p2: ********** WARNING: Filesystem still has errors **********
So, I still have errors, eh? Well, let’s just see about that.
sudo fsck -Va /dev/mmcblk0p1 fsck from util-linux 2.27.1 [/sbin/fsck.vfat (1) -- /dev/mmcblk0p1] fsck.vfat -a /dev/mmcblk0p1 fsck.fat 3.0.28 (2015-05-16) /dev/mmcblk0p1: 57 files, 2431/7161 clusters # sudo fsck -Va /dev/mmcblk0p1 fsck from util-linux 2.27.1 [/sbin/fsck.vfat (1) -- /dev/mmcblk0p1] fsck.vfat -a /dev/mmcblk0p1 fsck.fat 3.0.28 (2015-05-16) 0x25: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt. Automatically removing dirty bit. Performing changes. /dev/mmcblk0p1: 57 files, 2431/7161 clusters # sudo fsck -Va /dev/mmcblk0p2 fsck from util-linux 2.27.1 [/sbin/fsck.ext4 (1) -- /dev/mmcblk0p2] fsck.ext4 -a /dev/mmcblk0p2 /dev/mmcblk0p2: clean, 86265/972944 files, 705299/3896064 blocks
I popped the card out, put it back in the Pi and fired her up. It took a little longer while it straightened itself out but she’s up and running again. w00t!