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*
>
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?