Is anyone else seeing this problem, or know of a solution? Works fine in Wheezy, but in Jessie the following command generates an error and fails...
$ shutdown -rF now Code should not be reached 'Unhandled option' at ../src/systemctl/ systemctl.c:6316, function shutdown_parse_argv(). Aborting. Aborted
-F isn't documented on my system, what is it meant to do?
However, mine does the same.
pi@IridiumServer:~$ uname -a Linux IridiumServer 4.1.17+ #1 Fri Feb 5 23:21:02 GMT 2016 armv6l GNU/Linux pi@IridiumServer:~$ pi@IridiumServer:~$ cat /etc/debian_version
8.0 pi@IridiumServer:~$ /sbin/shutdown -rF now Code should not be reached 'Unhandled option' at ../src/systemctl/systemctl.c:6316, function shutdown_parse_argv(). Aborting. Aborted pi@IridiumServer:~$ /sbin/shutdown -r Must be root. pi@IridiumServer:~$
It performs a file system check during the boot process. I try to make a habit of doing this whenever power is inadvertently removed, or if there is a crash that requires me to remove power instead of following the standard shutdown process.
I hate the thought of the file system writing to corrupt blocks, oblivious to their presence.
Googling the error gives a comment from Debian developer Michael Biebl:
"The man page coming with systemd-sysv does not document that command line option. If you want to force an fsck on next boot, please add fsck.mode=force to the kernel command line (see man snipped-for-privacy@.service).
"systemd intentionally doesn't write a /force.fsck flag file to the disk to achieve that. You typically want to avoid writing to a file system if you are concerned about it's consistency. That's why the -F parameter is not supported (and won't be added)."
I think they're absolutely right here. DONT WRITE to a file system that might have been damaged. Instead, carry out one of these choices:
- edit the kernel command line during the next boot by adding ' fsck.mode=force' to force an fsck.
- select the recovery mode from the GRUB menu
- boot from a recovery disk
Which one you use is dependent on which Linux distro you're using. Some distros default to making GRUB boot straight into the default kernel so if you're using one of these, edit the grub configuration to make it show its boot menu. This will be needed it you go for either of the first two choices in my list.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
I think this discussion is about a Raspberry Pi, so no grub thingie, no booting from a recovery disk. Editing of commandline would be possible, but only in the file in /boot I think. (I rarely ever boot a Pi from a local screen so I am not sure)
Are you sure? It sounds rather like something that applies to Debian jessie on any and all hardware - and in support of that, Michael Biebl wrote 'disk', not 'flash' or 'SD card'.
Same here.
It looks possible to do what the OP wants by modifying the systemd units so that:
- on boot a flag file is set, e.g /forcefsck
- when shutdown is run the flag is deleted
This should have the effect of forcing fsck to be run on boot if the system was not shut down cleanly but not doing it after a tidy shutdown.
Am I right to think that /forcefsk is detected and fsck is run by the kernel without it needing assistance from anything else, such as systemd?
If that's true then I think that simply adding two services will do the trick: you need one to be run "After=basic.target" that creates the flag file and one to be run "Before=shutdown.target" that deletes it. There are probably other ways of automating fsck after unclean stops but this may be about the simplest and, by adding user-defined systemd service units, the changes should be protected from being clobbered by system updates.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
This is the Raspberry Pi group. On the Raspberry Pi, even when running Debian jessie, Grub is not used. The commandline lives in /boot/cmdline.txt and I don't think you can edit it during boot.
This file is detected in /etc/init.d/checkroot.sh and /etc/init.d/checkfs.sh which the people of systemd undoubtedly have replaced with something they think is much better and more like Microsoft Windows.
Thanks for the tip, Rob. It worked! I ran "sudo touch /forcefsck", which created a zero-byte file in the root folder. Then rebooted, and the mounted partitions were indeed scanned during the boot process. The zero-byte file was also handily removed afterward, which is nice because it means the above command can be run as needed.
a plausible argument but I would expect that most systems have a separate boot partition & that is unlikely to be the file-system that you wish to check
--
I'm always looking for a new idea that will be more productive than its
cost.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.