Spoiled Pi

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!

Post to Twitter

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.