The traditional /usr/sbin/shutdown command had "-f"/"-F" options to skip or force a fsck run just on the next reboot. It was implemented using a file that was touched before and removed after the boot. I understand that it is possible to edit the grub config, add some boot option, run update-grub, reboot, edit grub config again, run update-grub again - but a simple "shutdown -f now" would be much more convenient Also people don't have to be educated how exactly the boot flags name is and which parameters it can take. Having a fsck run as general rule but being able to skip it on occasions where things go unplanned would really good. Keep in mind, too, that many servers are only managed using ssh where admins do not have the possibility to quickly add a parameter to the kernel command line in the grub menu.
if there's need to use this option, then this is probably because one has the suspicion that the there's something wrong with the fs. In such a case it is the worst idea of all to make a change to the file system by touching a file in /. Asking for a file system fix by writing to it is really really wrong. Moreover, doing this is not possible in setups where / is mounted read-only. Hence, this sysv feature is actively dangerous and cannot cover all usecase, as such I am very strongly opposed to adding support for this to systemd natively. We shouldn't support functionality that is really obviously broken at a dangerous level, even if it traditionally was supported on sysv. Sorry! That said, it's not particularly hard to manually touch /forcefsck and then reboot. A "-f" switch is only marginally easier anyway. Hence not supporting this in systemd itself is not too much of a loss if people really really want to use it. I really want to avoid "blessing" something by supporting it in systemd natively, that it so obviously dangerous. Sorry!
The requested option was primarily the "-f" aka --skip-fsck to avoid a "ten minutes long" downtime. This option is of course only used if there is *no* suspicion regarding the filesystem but just the fear of a lengthy fsck run at the wrong time. The "-F" aka "--force-fsck" is mostly used not because of a specific suspicion but because there is a scheduled downtime anyways and the admin thinks that it can't hurt even if only e.g. 100 of the configured 180 days are passed. After all, it gives him 80 days in which a reboot would not to the lengthy fsck by default. So both options seem to have their valid use cases and can't really be called "dangerous" per se. It's nice that the "/forcefsck" still works, is there a "/skipfsck" as well? It is not mentioned in fsck(8) or shutdown(8). If so, it would be nice if this trick could at least be added to shutdown(8) as many admins whose distros switch to systemd will soon be wondering where -f is gone. I'm still in favour of adding the complete -f/-F options to shutdown again.
ext* upstream recommends (and new installs of common distributions follow that afaik) to not set the time-since-last-check / maximum-number-of-boots-without-check options at all. So a fsck would only occur when specifically requested by the user. Nevertheless, I think it would be nice to implement -f and especially -F through a better mechanism. EFI vars?
Yeah, doing this with EFI vars should be fine. And given that we already have code for that in place we could easily hack that up.
Now the bug title asks for the opposide of what I originally wanted: I wanted "-f" for "--skip-fsck" back! I'm glad to hear that ext* upstream decided that on new installtions the mount_count will no longer set but all existing filesystems still have it. On those systems skipping a fsck when the server has to be rebootet quickly is still a valid option.
EFI variable are no option to configure normal system operations or services. The facility is too fragile, known to brick devices, to be used for anything like that, its needs to be left alone to the boot loader or firmware specific tasks. The only sensible option to request a fsck is to use a flag in the superblock of the filesystem indicating that. /forcefcsk needs a writable mounted fs, but the superblock doesn't. Legacy filesystems requiring fsck to run should carry the support for it, in the filesystem and its fsck tool, and not complex facilities invented, to work around this limitation.
@Kai: what is the problem with forcing/skipping the fsck by creating a dummy file in the root file system like Linux did it for years? The filesystem is writable before the reboot when the /forcefsck is created, readable when fsck is called before mounting it and writable again after mounting so that the dummy file can be removed by some init script.
(In reply to cb from comment #7) > @Kai: what is the problem with forcing/skipping the fsck by creating a dummy > file in the root file system like Linux did it for years? The filesystem is > writable before the reboot when the /forcefsck is created, readable when > fsck is called before mounting it and writable again after mounting so that > the dummy file can be removed by some init script. Requiring to write to the content of a filesystem that one suspects to need a fsck is nothing but a really bad idea. https://bugs.freedesktop.org/show_bug.cgi?id=88330#c1 If legacy filesystems need that fiddling, then they have to provide the facilities to make that happen. It is not the job of the "init system" to invent insufficient and conceptually broken work-arounds for missing features in these legacy tools. https://bugs.freedesktop.org/show_bug.cgi?id=88330#c6
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.