Saturday 21 January 2017

File system repair: forcing fsck on Linux/Raspberry Pi

I lost remote (VNC) contact to my Pi at a critical time and could not even get a response to ping!


So I had no option but to break the connection to its supply, a 12Volt battery.


Result; corrupted files and a damaged file system.

At the time of the accident I had the Gambas IDE open and was editing my bird box monitor/control program. When I powered back up and opened the Gambas IDE, I found that most of the Gambas projects files looked OK, except that the main form code was completely missing.

At this point I decided to transfer the uSD card from the Pi-Zero to a Pi2B rig, so that I could work with it on a real display with a real keyboard and a real mains power unit.

sorting out Gambas


A closer look at the Gambas project files showed that the FMain.class file had zero bytes, while FMain.form looked ok, as did the other code module files. I noticed that some of the source files had backup files, which were denoted by a trailing tilde (e.g. FMain.class~).

This made me wonder just when a file gained a backup version, especially as the backup files were dated 4 days ago but seemed to contain my edits from yesterday.

By trial and error, it looks like a backup is created when you save the project AND a source file has been changed. So only the recently modified file is backed up.

As this project had been renamed and then saved, not all of the source files had backups, so I went through each one in the IDE and created a simple change (i.e. added a line break) then saved the project. It could be that the problems are not restricted to just losing FMain.class, and maybe the file dates have been screwed as well!

even bigger problems


The next thing I noticed was the file manager hanging when I tried to browse the root folder. I opened a terminal and used: cd .. to get back to root, then tried: ls -l to list the root files and folders. Again, this command hung.

I decided it was time to run: fsck. This must be run on an unmounted file system, which meant I either needed to take the uSD card out and do it on my laptop, or force the Raspberry Pi to run fsck when the system next boots.

A quick glance at the internet told me I needed to create an empty file at the root of the file system called: forcefsck. This would trigger fsck to run during next boot, check the file system, and delete the forcefsck file.

However, my brain was only partly assigned to this task, so I accidentally typed the command: mkdir forcefsck

Anyway, it worked. The file system was checked during the next boot, and I can now browse and list root folders (e.g. bin, boot, dev & so on).

And it was only some time later when I checked the command line buffer (history) that I realised what I'd done.

So forcefsck can be either a file or a folder!

The Raspberry Pi cmdline.txt file includes the string: fsck.repair=yes
...but I don't know what this is supposed to do. It didn't automatically run fsck to fix my problem, that's for sure.

I also could not see any confirmation that the file system had been checked by looking in /var/log/fsck. But it certainly paused during boot and did the check & repair stuff.

No comments:

Post a Comment