Rasperry Pi devices are becoming ever more common, as teaching tools, as playthings, and as controllers for various things (be it a physical device, service, or the ‘Internet of Things’). Unfortunately, at times they can be difficult to debug. The community is supported by a dedicated group of amateurs with varying levels of experience. When problems arise, you might find yourself booted into “Emergency Mode”.

One of my devices has an encrypted hard disk attached, for storing backups. Following a power outage, I discovered that I could no longer boot in to my Raspbian install. I was prompted for the encryption key, which was accepted. Then the system would stall, announcing

Welcome to emergency mode! sulogin: root account is locked, See sulogin(8) > man page for more details. The problem is, the emergency mode shell never activated! No matter how many times I pressed “Enter”, or any other key combination – it simply would not budge. I headed over to Google, which brough up a few results from the raspberrypi.org forums.

Within the first few posts, the not very helpful “Reinstall Raspbian” suggestion was made. Within a few more posts, the helpful pointer to this being an issue with the frustrating fstab system. Now, if you are using an SD only setup, that could well be the case. fstab is notoriously temperamental across most *nix systems, with various different versions around. Unfortunately, different flavours of *nix mount their filesystems slightly differently so often folks don’t know which options or commands are needed. Another (a Raspberry Pi staffer) suggested adding init=/bin/sh to the end of the /boot/cmdline.txt file (which is accessible from a Windows system). That does provide a shell, but you’ll often find that the filesystem is mounted as Read Only, making the changes to fstab somewhat tricky.

In my case, the problem wasn’t fstab – fstab was happy. The problem was running an encrypted USB hard drive off of the system. During the unexpected shutdown of the Pi, some of the journal blocks in the filesystem were corrupted. Once the encryption key was entered, the system reached the mount point for the drive, and received unexpected results from the filesystem. No amount of messing with fstab was going to sort that out, other than commenting out the mount point for the external drive. There is, however, a far easier diagnosis method if you’re using an external HDD.

Diagnosis

1. Switch off the power to your Pi
2. Switch off / disconnect your external drive
3. Switch the power back on
4. Wait for everything to complete

If you get your standard login prompt, the problem lies with the external hard drive. Log on to your Pi, then:

If you are using a luks encrypted filesystem on the drive, follow all of these steps, otherwise skip ahead!

1. sudo cryptsetup luksOpen /path/to/physicaldevice mountpointname
2. fsck /dev/mapper/mountpointname
3. Accept any repairs suggested
4. sudo mount /dev/mapper/mountpointname /path/to/mountpoint
5. sudo reboot

If you are using an unencrypted external drive:

1. sudo mount /dev/physicaldevice /path/to/mountpoint
2. fsck /path/to/mountpoint
3. Accept any repairs suggested
4. sudo reboot

Hopefully, that should fix your problem. Note: This will also potentially resolve issues with the SD mount also. Simply replace the path to the mountpoint you wish to check, e.g. sudo fsck / to check the root filesystem.

Hope this helps!
Two Up IT