How to fsck? (Sarpi on an RPi)

Since the RPi doesn't have a RTC, how do you do a fsck of the whole file system?

Originally Posted by arfon Since the RPi doesn't have a RTC, how do you do a fsck of the whole file system?

Hmm... not sure how a RTC is related to running a filesystem check.

You can force a fsck at boot time. This Slackwiki page offers some good information: https://www.slackwiki.com/Forced_Fsck

You can set the fsck value (the last value of each entry) in /etc/fstab to "1" for the root filesystem and "2" for /boot - for example:

~# cat /etc/fstab

/dev/sda2       swap             swap        defaults              0   0
/dev/sda3       /                ext4        defaults              1   1
/dev/sda1       /boot            vfat        fmask=177,dmask=077   1   2

You can boot another instance of Slackware ARM on your Raspberry Pi and run a fsck check on any filesystems within partitions that exist on an SD card or HDD/SSD storage devices connected via USB...

 # fdisk -l /dev/sda

Device     Boot    Start       End   Sectors   Size Id Type
/dev/sda1           2048    403455    401408   196M  b W95 FAT32
/dev/sda2         403456  17180671  16777216     8G 82 Linux swap
/dev/sda3       17180672 937703087 920522416 438.9G 83 Linux

# e2fsck -fvn /dev/sda3

You shouldn't run e2fsck or fsck on any mounted filesystems. Trying to repair errors on a live filesystem has the potential to royally screw things up...

man e2fsck

Note that in general it is not safe to run e2fsck on  mounted  filesys
-tems. The only exception is if the -n option is specified, and -c, -l,
or -L options are not specified.   However, even if it is  safe  to  do
so,  the  results  printed by e2fsck are not valid if the filesystem is
mounted.   If e2fsck asks whether or not you should check a  filesystem
which  is mounted, the only correct answer is ``no''.  Only experts who
really know what they are doing should consider answering this question
in any other way.

So, you can do a dry-run fsck on any live filesystem (i.e. without attempting to make any changes) by using the "-N" option, which is quite safe to do...

# fsck -N /dev/mmcblk0p3

See:

man fsck

 -N     Don't execute, just show what would be done.

Hope this helps.

"Hmm... not sure how a RTC is related to running a filesystem check."

Because fsck tries to fix dates in the future-

https://access.redhat.com/solutions/53210

https://bugs.debian.org/cgi-bin/bugr...cgi?bug=559776


I assume that the Sarpi included fsck doesn't attempt to fix dates?

Originally Posted by arfon "Hmm... not sure how a RTC is related to running a filesystem check." Because fsck tries to fix dates in the future- https://access.redhat.com/solutions/53210 https://bugs.debian.org/cgi-bin/bugr...cgi?bug=559776 I assume that the Sarpi included fsck doesn't attempt to fix dates?

OK. So if you have a time-keeping issue with Slackware ARM or an ARM device without a RTC installed, there's a few things you can do to overcome any issues that may arise as a consequence.

You can install a very cheap and affordable RTC on most ARM devices with little time and effort involved. [easy solution]

You can use code in a file (e.g. /etc/rc.d/rc.local) to set the correct date/time at boot. [very easy - see this example on SlackDocs]

You can manually set the correct date/time periodically or at boot time. [potentially too much like hard work for most people]

[EDIT]
If your ARM device or Slackware ARM system is suffering badly from unreliable time-keeping, and you do not have an RTC installed, you could create a file in /etc/cron.hourly, or /etc/cron.daily, or /etc/cron.weekly, or /etc/cron.monthly, (as required) to set the correct date/time periodically from an Internet or local network based NTP server. For example:

root@slackware:~# nano -w /etc/cron.hourly/my_system_time-keeper.sh

#!/bin/bash

# set system time from ntp server 
/usr/sbin/sntp -Ss pool.ntp.org > /dev/null 2>&1

root@slackware:~# chmod +x /etc/cron.hourly/my_system_time-keeper.sh

You either need a RTC installed, or access to the Internet in order to set the time automagically. Otherwise you need to do it manually.
[/EDIT]

SARPi installers includes a combination of content from the official Slackware ARM initrd-armv7.img initial RAM disk and the Raspberry Pi GitHub repository. So, fsck is exactly the same file as that which comes with Slackware ARM. SARPi is not an operating system and does not re-compile anything provided by Stuart in his Slackware ARM distribution. Basically, SARPi makes use of exactly what Stuart provides and re-packages it into a purpose-built installer and system packages for use on the Raspberry Pi devices.

The RPis all have access to the internet but, I can't count on the connection being reliable and I assumed that an 'at boot' fsck happened before all of the daemons (e.g. ntpd) and RC files were loaded.

In the past, I have had cron write the time in a tmp file and on boot check to see if ntpd has updated the time and if it didn't, use the last time to set the time/date 'close enough'. The problem is, I need to fsck the file system every so often and I think the rc.local stuff gets executed AFTER fsck happens at boot.


I've been running SARPI on some RPis for years without a file system check and they are now randomly locking up. File system corruption seems to be the most likely cause.

Originally Posted by arfon The RPis all have access to the internet but, I can't count on the connection being reliable and I assumed that an 'at boot' fsck happened before all of the daemons (e.g. ntpd) and RC files were loaded. In the past, I have had cron write the time in a tmp file and on boot check to see if ntpd has updated the time and if it didn't, use the last time to set the time/date 'close enough'. The problem is, I need to fsck the file system every so often and I think the rc.local stuff gets executed AFTER fsck happens at boot. I've been running SARPI on some RPis for years without a file system check and they are now randomly locking up. File system corruption seems to be the most likely cause.

You haven't been running SARPi as an operating system, at any time. You have been running the official Slackware ARM operating system the whole time, if you've installed it using the SARPi installers.

An automated fsck at boot happens before the root filesystem is mounted. You can force a filesystem check at boot time, as was previously referenced on the https://www.slackwiki.com/Forced_Fsck page - read /etc/rc.d/rc.S and 'grep forcefsck' to view the code immediately below the first instance of it to see how this works. You can also choose to turn off fsck at boot time - I always do (i.e. with the last column of each entry in /etc/fstab set to "0" zero where applicable).

It might be prudent to address any filesystem corruption in your case, as previously mentioned, by running another instance of Slackware ARM and doing a filesystem check on the SD card or storage device where the suspected problem is. If you are using SD cards to run the Slackware ARM operating system then always have spare cards available and always make frequent backups, because not all SD cards are the same and some are more prone to failure and being problematic than others. SD cards have usually failed when I've least expected it, or at the most inconvenient opportunity, in my experience. Even some of the best designed SD cards do not offer the longevity of a HDD or SSD storage device and are nowhere near as reliable/dependable over prolonged periods of usage.

Yes, /etc/rc.d/rc.local is one of the last initialisation script to run before the login prompt appears - see http://www.slackware.com/config/init.php for more details on these scripts and the order of things.

So, to summerise, and to make it easier, and to keep things simple, and because you cannot count on your Internet connection being reliable, think about installing a battery-backed-up RTC on your Raspberry Pis. Rather than spend a lot of time over multiple or long periods, sorting out any issues that arise from inaccurate time-keeping, you could invest a few bucks on this and have peace of mind. Even a lowly DS1302 or PCF8523 based RTC would suffice. Places like eBay sell them very cheap with free delivery.

Originally Posted by arfon Since the RPi doesn't have a RTC, how do you do a fsck of the whole file system?

This is a good question!
I assume you mean of the root filesystem?

What you can do for supported Hardware Models is:

cd 
cat << 'EOF' > /boot/local/load_kernel_modules.post
/bin/ash
EOF
root@zippy:~# os-initrd-mgr 
Searching for local customisations ... 
Found: /boot/local/load_kernel_modules.post

Unpacking /boot/initrd-armv7 ...
Adding customisations ...
Repacking /boot/initrd-armv7 ...
Successfully added local customisations to the OS InitRD.
root@zippy:~#

Then reboot.

During boot you'll be presented you a root shell within the OS InitRD from which you can launch fsck.
You need to ensure that you have access to the console during boot - typically with the serial console, or using the USB keyboard/mouse.
When you're done, simply type 'exit' to kill the shell and the boot process will continue.

You could also automate an fsck of the root filesystem (perhaps if you have trouble gaining control) like this:

cat << 'EOF' > /boot/local/load_kernel_modules.post
fsck -y $ROOTDEV
EOF
os-initrd-mgr

Depending on use, you can mount the root file system read-only, mitigating need for fsck. Handy for headless reboot, when there is no i/o for fsck.