Description of problem: In Mageia 2 with legacy SystemV support, Mageia 1 and older Mandriva releases, the file /.autofsck is created when the system boots. When the system is shutdown or rebooted cleanly, the file is removed. Thus, if the file exists when the system boots that means that the system was not halted properly. Then, based on the value of AUTOFSCK_DEF_CHECK set in /etc/sysconfig/autofsck, all the filesystems are checked or not at boot time. However, in Mageia 2 with systemd support, the file /.autofsck is not created. Thus, even if the system suddenly powers off, in the next boot the file will not exist, and the filesystem check will not be forced (although, as far as I know, it will be made if the filesystem declares itself in a dirty state; however, this is not the same behaviour shown with SystemV scripts). As far as I can tell, when SystemV is used, the /.autofsck file is created at boot by /etc/rc.d/rc.sysinit (line 1085), and removed at halt by /etc/rc.d/init.d/halt (line 226). The configuration values set in /etc/sysconfig/autofsck are also used at boot in /etc/rc.d/rc.sysinit (line 415 and below). When systemd is used it seems that the /.autofsck is removed as stated in /etc/tmpfiles.d/mandriva.conf (line 4), although I do not know when it is removed. Anyway, it seems that the file is not created anywhere, and I have not found if the configuration values are used somewhere either. Version-Release number of selected component (if applicable): initscripts-9.34-20.mga2 How reproducible: Every time you boot a Mageia 2 system that uses systemd. Steps to Reproduce: 1. Boot on a Mageia 2 system with systemd-sysvinit installed. 2. Look for .autofsck file in / (it will not be there, but it should). 3. Install sysvinit-legacy package (this will remove systemd-sysvinit package) 4. Reboot 5. Look for .autofsck file in / (it will be there, as it should).
CC: (none) => mageia
Hmm, this is a bit of an interesting system for fsck. I'm not really a massive fan of writing such files every boot as this would generally prevent such things as read-only roots which should likely be encouraged. That said, it is a file that is supported and we should really ensure it works as advertised. In dracut there exists support for both /.autofsck and /forcefsck (the latter meaning to be a manual way to trigger the fsck on next boot - just "touch /forcefsck" before rebooting). That said I do not see specifically where the .autofsck is meant to be written with systemd. It's maybe something that has been specifically deprecated... I'll ask upstream but really I think the only sensible place to do this is in dracut - if the rootfs indicates it's r/w then dracut should mount it as r/w then touch the file. When the system re-enters the initrd when shutting down, dracut should then remove the file again before it unmounts the rootfs. This is the only way I can see such a scheme working as intended these days. I'll ask Harald (upstream dracut) what the current story is here.
(oh and just for reference the tmpfiles stuff is processed by "systemd-tmpfiles-setup.service" or "systemd-tmpfiles-clean.service")
OK, so I've discussed this with a few people now. Here is the rundown: The /.autofsck file is deprecated. Modern filesystems support dirty flags in the superblock and have done for years so they know when they should be fsck'd. Normally journaling fs's can just recover their journal to avoid a full fsck but this should all be handled automatically without any need for fragile systems pasted over the top. In other words. /.autofsck is really a hack that was used to work around really dumb file systems and we no longer need to support it (it's not like we support / on FAT anyway!). Arguably things need to be tidied up a bit (e.g. the sysconfig file). Regarding /forcefsck file, you can use this to force an fsck on next boot (just touch the file) but doing so is a pretty bad idea. I mean if you suspect your fs is fubar, you would likely remount it ro immediately then reboot. If you have to touch a file on the fs itself to trigger the fsck then it's not exactly very bright if you suspect some form of corruption is going on as any changes you make on the fs could make the situation worse! It would be better to use the fsck.mode=fsck kernel command line argument to force a root fs check. Longer term we may support using an EFI variable that can be set and then looked at next boot. I hope this information is useful. I'd welcome any feedback you have on the matter.
(In reply to comment #3) > The /.autofsck file is deprecated. Modern filesystems support dirty flags in > the superblock and have done for years so they know when they should be fsck'd. > Normally journaling fs's can just recover their journal to avoid a full fsck > but this should all be handled automatically without any need for fragile > systems pasted over the top. I suspected that it was deprecated. However, as it was still working in SystemV I thought that it would be better to report it, just in case it was a feature that slipped through when the change to systemd was made. > In other words. /.autofsck is really a hack that was used to work around really > dumb file systems and we no longer need to support it (it's not like we support > / on FAT anyway!). Then, as far as I'm concerned, this bug can be closed. > Arguably things need to be tidied up a bit (e.g. the sysconfig file). Note that, besides being referenced in the files mentioned in the original report, ".autofsck" and "/etc/sysconfig/autofsck" are both referenced too in "/usr/lib/dracut/modules.d/98usrmount/mount-usr.sh" and "/usr/lib/dracut/modules.d/95rootfs-block/mount-root.sh". Those files belong to the dracut package. > I hope this information is useful. It was, thanks for your efforts and the detailed explanation :)
Yeah it was entirely possible that it was a needed feature that slipped through the net with the conversion to systemd. As it turns out it was an unneeded feature that slipped through the net :) The issue was really that we should have stopped supporting it years ago under sysvinit but these kind of tidyups rarely happen and you find unneeded features just bumbling along. It's kind nice doing a big change (to systemd) as it roots out all this kind of cruft :) As for dracut, yes, it's still honoured in dracut if the files exist. I think that's OK, but it will likely eventually die there too at some point in the future. Thanks for the report :) In lieu of a DEPRECATED bug resolution, WONTFIX will have to suffice.
Status: NEW => RESOLVEDResolution: (none) => WONTFIX