I think any suggestion about warning the user before doing the fsck is probably better off in Bug #22460 . However since people are discussing stuff here...
Mark: Oof. This sounds a dangerous because if an fsck stops that almost certainly means it needed user intervention to work out what to do next. Additionally checking on shutdown is hard because you have to guarantee that the filesystem has been mounted read only in case you need to change anything. I can also see this from the remote machine perspective where I do a remote shutdown of a machine via halt only to have it kick off a massive fsck which I can no longer interrupt. Additionally you run into the Windows XP "problem" of people saying "but I just wanted it to power off!" as it uses shutdown as an opportunity to install critical updates. Imagine you are given a machine and just as you reboot the first thing it says is "can I check this disk?". You say yes not knowing how long it will take. Hours later the check is still going and finds a fault which then promptly causes your machine to power off leaving you to spend several hours getting back to the fault when you power the machine back up... which then tells you to launch fsck interactively and asks for the root password. You log in and wait a few more hours while you do an interactive fsck because the shutdown fsck had no where safe to write that it needed to do and interactive fsck on boot (this can probably be worked around but still). The best short term thing I think you can do is a irritating cron job that kicks in every 4 months and says "checking your disks for failures before they go bad is a good idea. Do a backup now then check disks? Just check disks? ". I suspect the very best thing that can be done is an online fsck hat happens in the background while your system is "running" and is short. -- New ext3 partitions should not have max-mount count https://bugs.launchpad.net/bugs/3581 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
