4

I'd like to use fsck on every boot of my RPi 3B+ server. To do this I will be using tune2fs -c 1 /dev/mmcblk0p2. When fsck runs I'd like the output to be added to a log file in /home/pi/fsck.log with the date and time above it, for example,

04/19/20 14:00
(fsck log)

How would I configure the RPi to do this?

dominic03
  • 347
  • 1
  • 16
  • Why not just use the redirect as normal `>` or `>>` when you run fsck or am I missing something? Also is this on an SD card or HDD / SSD and why are you doing it? –  Apr 19 '20 at 18:12
  • SD card. I'm doing it so I can track FS errors and replace the SD card if needed. WDYM by 'redirect as normal when you run fsck', if it's automatically running at boot how could I do this? – dominic03 Apr 19 '20 at 18:21
  • I had assumed you where controlling when fschk runs. File system errors can occur for many reasons other than the SD card failing. The SD cards I have had fail in cameras just go write only - other file system errors are normally due to me pulling the wrong plug (solved by colour coded cases and a silver sharpie now). –  Apr 19 '20 at 18:50

1 Answers1

6

There is no need to run tune2fs -c 1 /dev/mmcblk0p2 to run fsck. As you are not "tuning" any fs parameters, using tune2fs as a proxy for fsck simply adds overhead & may slow the boot process by a small amount.

As strictly a fine point, I don't think that tune2fs runs fsck at all - it runs e2fsck. In current versions of the OS, fsck serves as a "wrapper" or "front-end" to provide legacy support. Typically, fsck simply calls e2fsck to do the real work. Note also that while using the plain fsck will get the job done in most cases, it may not be capable of passing options you wish to use with e2fsck.

That said, here's a recommended way to run fsck on every boot:

Use your editor to add the following to /boot/cmdline.txt (recommended):

fsck.mode=force

$ nano /boot/cmdline.txt
...
 
# FROM:  
console=serial0,115200 console=tty1 root=PARTUUID=6c586e13-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait  

# TO:  
console=serial0,115200 console=tty1 root=PARTUUID=6c586e13-02 rootfstype=ext4 elevator=deadline fsck.mode=force fsck.repair=yes rootwait

Other methods to run fsck at boot (not recommended):

You can also use the legacy technique of creating a file named forcefsck in the root of the filesystem /; i.e. sudo touch forcefsck. However, this may be ill-advised:

  • the file /forcefsck is removed before booting is completed - which means you'll need to automate adding it (e.g. a cron @reboot job) following each reboot.

  • a warning to use the method above (fsck.mode=force) will be issued by systemd to var/log/syslog:

Please pass 'fsck.mode=force' on the kernel command line rather than creating /forcefsck on the root file system.

logging fsck results to /home/pi/fsck.log

fsck results are logged to var/log/syslog by default. Rather than trying to redirect or duplicate those log entries to another file, I'd suggest the following:

$ less /var/log/syslog

This will load the log into the less pager. Once the logfile is loaded, search and highlight all instances of fsck by entering /fsck. You may now scroll through the logfile, and your attention will be drawn to each highlighted entry for fsck. This has the advantage of seeing potentially relevant events which are not generated by fsck.

As an alternative to the above, if you strictly want to see log entries generated by fsck, journalctl is a friend:

$ journalctl -u systemd-fsck*
Seamus
  • 18,728
  • 2
  • 27
  • 57