Unable to cancel a fsck

Same problem exists in gutsy. Very annoying if you're about to give a presentation!

I figured out a long time ago to disable the max-mount-count (tune2fs -c -1 /dev/sda1).
Still, seen from a usability perspective I think this is serious bug.
Completely disabling automatic fsck isn't the best strategy anyway.

This is more than just an inconvenience - occassionally i'll boot my laptop on a short train journey knowing i've got enough battery left for 10 - 15 mins, then fsck kicks in and there's a fair possibility that the battery will be dead before the fsck finishes.
I'd quite like to have the option to cancel the fsck back, and just boot as normal.
Ideally the fsck just wouldn't run when when on battery power - someone else seems to have reported that as #116289

Try:
http://wiki.ubuntu.com/AutoFsck

autofsck sounds like a good solution, but it's something that should really behave sensibly by default.

I just upgraded to hardy and at reboot, the system did an fsck, but it was nicely integrated in the graphical boot and it was saying that pressing "esc" key would cancel it.
Could you check if your problem isn't solved with hardy ?

It is possible to cancel fsck in Hardy.

This "bug" bites me all the time. Autofsck has another problem that's even worse, though, so I had to remove it: If Autofsck prompts that a disk needs checking, and I select "OK" on reboot, the system comes back up, checks the disks, then shuts down!! I'd rather sit through the disk checking with no warnings when I reboot than have the computer shut down. Really, though, cancelling a running fsck should be included in ALL linux distributions and having a tiny piece of software like Autofsck that has its own problems is not a solution.

I'm running Jaunty, and I boot verbose (I removed "quiet" and "nosplash" from my menu.lst) for other reasons. Pressing ESC, ctrl-C, ctrl-D, ctrl-alt-delete do nothing. (well actually ctrl-alt-del does cancel the fsck, but you have to press ctrl-d IMMEDIATELY afterwards (and I mean literally immediately) to avoid a reboot (which just triggers another round of fsck's)... and even if you DO manage to press that quick enough, there are still several daemons that don't start, like networking for example, that must be started manually). no networking, no ssh, no remote management, no server useability. This is quite a conundrum that could easily be solved by not disabling the ability to cancel and not implementing such a policy in future releases.

My /, /boot, and /home are on smaller high-availability RAID arrays, and not only that, my / is ReiserFS so is barely affected by this problem. Checking just those wouldn't take very long. The problem is I have nearly an additional 1.5TB of ext3 data across several drives in different RAID configurations. It's these checks that really kill me, and they could be all run while the system is fully up and running in runlevel 5. I don't want to change the frequency of checks, either, because if I don't NEED to use the box, I can just let it do its scheduled fsck and when it's finished, it's finished.

What would really be nice is if the functionality that should be there (ctrl-c to cancel on an ad-hoc basis) was still there. The decision to remove this feature was not fully thought out, and it should be there once again, as it always has been in Debian, RHEL, and used to exist in Ubuntu until somebody made the unwise decision to disable it.

Again, another piece of software, i.e. autofsck is NOT a valid solution.