| Summary: | /.autofsck is not created when using systemd | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Daniel Calviño Sánchez <danxuliu> |
| Component: | RPM Packages | Assignee: | Mageia Bug Squad <bugsquad> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | mageia |
| Version: | 2 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | initscripts-9.34-20.mga2.src.rpm | CVE: | |
| Status comment: | |||
|
Description
Daniel Calviño Sánchez
2012-06-18 19:22:00 CEST
Remco Rijnders
2012-06-22 08:08:57 CEST
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 =>
RESOLVED |