making bootup fsck more user-friendly
I already checked this problem with Google and with my LUG, and would
like to ask on this mailing list before I fire off a bunch of feature
requests in the Debian BTS.
===== FROM MAIL TO MY LUG =====
I've tried Googling for this but haven't found much info, so asking here.
Every X days or Y reboots, Linux (on my home PC, which I boot & shut
down 2x each day) wants to scan partitions for errors at startup.
While this is a bit annoying (can't use the PC for 10-20 minutes), I
usually let it finish and read a book while waiting.
But at other times I want to use the PC quickly for something, and
waiting for fsck to finish isn't an option. The problem is, hitting
Ctrl+C in the middle of boot fsck leaves your root partition in
read-only mode, and the machine has a lot of boot problems, and takes
a long time. I've tried this a few times this morning when I was in a
hurry (reboot, ctrl+c during fsck, hit boot problems so reboot again),
but in the end was forced to let fsck finish.
Is there a way to interrupt the bootup fsck 'cleanly', so that it will
remount read/write, and retry the next time you boot?
Even better would be a way to get fsck to run in the background after
you're already logged into KDE. Maybe not to actually fix problems (I
understand this is hard to do in r/w mode, while being actively used,
for technical reasons), but at leat to flag them for the next 'real'
fsck so they can be checked and fixed quickly then if they aren't
===== A FEW (TRIMMED FOR BREVITY) REPLIES FROM MY LUG POST =====
On Fri, Jun 13, 2008 at 10:08 AM, Morgan Collett
> Ubuntu 8.04 / hardy supports cancelling the fsck on boot cleanly with
> Esc (or is it Ctrl-C? I haven't tried it myself.)
> You can change the number of boots:
> You can change it to once a month:
> You can try AutoFsck which does the fsck on shutdown instead:
> http://micrux.net/?p=52 AT YOUR OWN RISK of course...
On Fri, Jun 13, 2008 at 10:12 AM, Deon Bredenhann
> If you leave the box on or running through the night, just force an fsck
> once a week.
> Have a cron entry at 2 in the morning run 'shutdown -F -r now'
> This will reboot and force fsck to run. If you do this on a weekly base,
> you will most likely not run into the I'm-in-a-hurry-now problem. Would
> like to know what other solutions people have out there.
On Fri, Jun 13, 2008 at 10:12 AM, Liam Smit <firstname.lastname@example.org> wrote:
> I'd suggest increasing the number of reboots between file system
> checks. Have a look at tune2fs.
> A more drastic approach would be to change to a different file system
> which does not require such frequent fsck.
>> Is there a way to interrupt the bootup fsck 'cleanly', so that it will
>> remount read/write, and retry the next time you boot?
> Probably not once it's running i.e. there is an element of risk
> involved in stopping a running fsck. Rather prevent it from starting.
>> Even better would be a way to get fsck to run in the background after
>> you're already logged into KDE. Maybe not to actually fix problems (I
>> understand this is hard to do in r/w mode, while being actively used,
>> for technical reasons), but at leat to flag them for the next 'real'
>> fsck so they can be checked and fixed quickly then if they aren't
> That would probably corrupt the file system being checked unless it
> was first unmounted.
I researched the options they mentioned, and I'm not happy with the
situation (at least with Debian Unstable, I don't use Ubuntu).
I want to submit these feature requests, but first I'd like some
feedback from this list before I do so:
- When it's time (during startup)to run a full fsck, give the user a
few seconds to hit ESC before running them
- /sbin/shutdown allows the user to (any of these would help):
* Force a fsck during the restart (-rF), and then to shut down the system.
* Force a fsck during shutdown, after drives have been unmounted
+ But only if an fsck is due the next time the machine boots?
- fsck allows the user to abort cleanly with ESC (fsck will be
retried on the next boot)
- ability for a readonly fsck on a r/w filesystem to gather info to
make a later fsck on the filesystem as r/o to find and fix problems