Ubuntu

Should be warned of upcoming forced fsck

Reported by Vidar Braut Haarr on 2005-09-25
40
This bug affects 2 people
Affects Status Importance Assigned to Milestone
sysvinit (Baltix)
Undecided
Unassigned
sysvinit (Ubuntu)
Wishlist
Unassigned

Bug Description

It seems that every 30th time I boot, I'm dropped to this horrible terminal
thing with a progressbar made out of ='s that checks my HDD or something.

I'd much rather that on the 29th boot, you got a message after logging in
warning you about this, and also giving you an option to run the check at any
point in the current session.

Sometimes when you boot, you're in a hurry - and then this thing pops up :-) I'd
much rather get that warning and then run it some time during that session when
it suits *me*, and not have it forced upon me on the next boot (which would
still happen, of course, if I chose not to run it during the session.)

I had no idea where to file this, so I hope "initscripts" is a good place :-)

Tormod Volden (tormodvolden) wrote :

Would be great to have an option to do the file checking in the Logout menu: "Check file systems and shutdown"

This option could for instance show up after 25 mounts.

Of course, if the check fails, and asks for manual intervention, the computer will not shutdown... But that's a minor annoyance.

Changed in sysvinit:
status: Unconfirmed → Confirmed
Sitsofe Wheeler (sitsofe) wrote :

This is very similar to Bug #3581

What? No, it's not similar at all ...

I have no idea how to unmark it as duplicate - someone please help me do that.

Georg Brzyk (gbrzyk) wrote :

This is also very annoying behaviour if you're on a laptop with limited power supply. It takes away precious battery time and is irritating if you want to check something in a hurry.
The above proposal would be nice. Either that or add a check at boottime whether the computer is on A/C or battery and postpone the check until the next boot in the latter case.

gunksta (gunksta) wrote :

I ran a poll about this on the Ubuntu Forums. I offered three options on my poll.
Option 1: Keep it like it is
Option 2: Do away with it entirely
Option 3: Make sure the user can opt out of it when it is inconvenient.

Overwhelmingly, the community has voted for #3. If is a good idea to periodically check the hard-drive for errors. I don't have a problem with that at all. But, as a laptop user I have learned that Murphy's Law guarantees it comes up at the most inconvenient of times.

I think the behavior should be changed in the following ways:
On Boot #29: You should recieve a message warning you that your system will need to perform the hard-drive check upon the next reboot. It's simple, not intrusive, and would give laptop users a chance to let it happen at a convenient time (When the computer is NOT attached to an over-head projector for instance.)

On Boot #30: The screen should tell you how to manually over-ride the scan. I have heard on the Ubuntu Forums that CTRL-C Followed By Ctrl-D will allow you to escape the scan. I haven't tried this yet. I will next time my laptop scans the hard drive. If this is true, this should be clearly labeled for the users and should not be treated like an "Easter Egg" for "those in the know".

--andy

I agree with Andy, obviously, since his first suggestion is identical to the one I made in my initial description. Except I also think the user should be able to run the fsck during session 29 in order to avoid it the next boot.

About letting the user know how to cancel it, I also agree. In any case the way it is done now at boot is horrible, a ASCII progress bar and lots of technical jargon. I'd propose changing the usplash progress bar to track the fsck progress and give the user a better description of what's happening (something simple), and also do a screen clear so the other boot messages are not shown during the check.

Anyway, maybe you could link to the forum thread here for reference, Andy?

Alexandre Otto Strube (surak) wrote :

Vidar, why this is not similar to #3581? They look preety much the same to me...

Bug 3581 is about removing the fsck entirely by setting the max mount count to 0.

This bug is about giving the user a warning before the forced fsck happens.

Sitsofe Wheeler (sitsofe) wrote :

ext3 partitions are journalled and thus anything that this fsck is likely to catch will probably result in scary things happening to the data on the disk anyway (if the hardware is going bad for example). Neither MacOS X, Windows XP, Fedora, SUSE or Mandriva default to having an fsck done after X boots and with disks only increasing in size you can be waiting forever if you do run one.

Far better to have people opt in to this via some archane switch that default it to on for user desktops.

You can't run the checks in a running session because you need to remount the disks read-only again.

Changed in sysvinit:
status: Confirmed → Rejected

Right, but it's still possible to warn the user in the 29th session that a fsck will happen next boot, which is what the bug is really about.

I would reopen the bug, but I have no idea how to do that, or if I can at all.

Brandon Barry (bbarry) wrote :

A forced disk check every thirty boots is quite bad for users with 750GB drives. The check takes an extremely long time. Users may believe their system to be broken.

The check itself is essential, but the current behavior should be easy to discover and easy to modify.

Vassilis Pandis (pandisv) wrote :

Reopening, as this is not a duplicate of 3851 and has not been resolved.

Changed in sysvinit:
status: Rejected → Confirmed
Jacob Winski (winski) wrote :

There is a program that does what the original author of this bug wanted: "I'd much rather that on the 29th boot, you got a message after logging in warning you about this, and also giving you an option to run the check at any point in the current session." The program is called Bonager: The Boot Scan Manager. The only small difference being that it does NOT do the check in "the current session" because that is not possible. User must restart the computer for a scan to take place.

This program is available in the Ubuntu forum. URL:
http://ubuntuforums.org/showthread.php?t=295262

This is a story that was starting nicely and ended up sadly...

Let's take some fake user name to set it up. So Sean has a recent computer but not a legal license for the running OS. After a while, it becomes cluttered with viruses and spyware. I take this good opportunity to present Ubuntu with the Live CD and how he could work with this system.
Sean is enthusiastic, he was a completely new user to the previous OS and does not mind having a different one as long as it works.
So I install him Ubuntu in place of the other OS. I configure him Evolution, show how to import photographs and use F-Spot, etc. I made a happy user.
The problem is that one and a half month later, he was starting his computer and saw a screen he has never seen before full of characters. It reminds him of the blue screen of death of the previous OS (even though he does not know this terminology himself), so he shutdown and restart the computer and a few minutes after he was calling me because everything was broken (hard drive partly corrupted). The problem was that I'm leaving 350km from him and that I could not repair it and I could not find anyone near his village who knew Linux...
End of the story, he went buying Windows because he had a neighbour that could help him out with this OS...

My personal conclusion is that this problem is related to the current bug and it is a major problem for non-geek human beings. I do not know if the "normal" human beings can decide whether or not they want to have the disk check during this session or the next, but they do not want to see a textual interface when the disk is check.
Reading the above comments and because of my own recent experience, I would suggest:
  - no check forced when on battery
  - when checking, Ubuntu boot splash should remain, no text-based interface. The user shall be notified that his boot might take longer than usual, but he can speed it up by pressing key "something".
  - if check was skipped in previous step, a small information message (like the one for unsafe removal or battery almost empty) should tell the user what was skipped and that it will be performed next time, and with a link to some help on this topic.

Mathijs Vogelzang (mathijs) wrote :

What is the status of this item?
Importance is now listed as wishlist, but I think that according to the posts above and the conducted poll on the forum this is an important issue for many of us.
Just a small message on how to cancel the current check would make things a lot better, but more work is needed for a definitive solution.

Jim Hutchinson (jphutch) wrote :

Bonager (mentioned above) is great workaround for this "bug" but a fix that gave users more control would be nice. In fact, we should be allowed to choose to run the scan on boot up or shut down. Most of the time, I'd rather it run on shut down because I'm done and don't care if it runs a check but on boot up, I have to wait. We also need the option to bypass this if on a laptop on battery. Or maybe it should be smart enough to skip running if you are on battery.

Huygens (huygens-25) wrote :

@Jim
It seems also at first thought better from my usage point of view to have the scan at shutdown. Because, I usually shut down my computer and go doing other things without looking at it.
However, the "shutdown" phase is also used upon reboot (at least, I do not know if the scripts executed upon shutdown can guess if it is a reboot or shutdown...) And I am not sure then if I prefer to have the scan on shutdown/reboot...
But anyway, that's an idea :-)

Oliver Gerlich (ogerlich) wrote :

The forced fsck is really annoying, and dropping back to text mode and not being able to easily stop the check makes it worse. I like Huygens suggestions and would formulate it as this:

Short-term fix:
- don't do the check if laptop runs on battery
- make it easier to cancel a check
- make it possible to tell the system to not run proposed fsck check now but do it on next boot
- maybe integrate progress reporting with usplash

Long-term solution: do such checks at shutdown. On shutdown, GNOME shutdown dialog could ask the user whether he'd like the system to do some health checks before switching off (I think asking would be nice so users are not surprised, but exact usability details are another topic). The system could then do fsck, maybe even start memcheck86 afterwards (would probably need some heavy magic), and do whatever other low-level checks there are. It would be important that the user can still switch off the machine during the checks without problems. Results of the checks could then be evaluated by the system after next boot, and a tray notification (or whatever) can tell him that the disk has problems, suggesting a solution.
Guess this long-term solution needs an own spec :-)

Note: the problem about dropping back to text mode for fsck is also described in bugs 38303 and 67453 , and the problem about not being able to cancel is described in bug 65683 .

Matthias Niess (mniess) wrote :

As far as I can see from the corresponding scripts /etc/init.d/checkfs.sh and /etc/init.d/checkroot.sh a check if the system is running on battery is already done.

Also these scripts could be easily modified to give the user something like a 10 second delay to cancel the check, and start it otherwise. Is similar modification was proposed in the German Wiki:
http://wiki.ubuntuusers.de/Dateisystemcheck#Ask
The text is German but the script I'm talking about is commented in English.

Doug Holton (edtechdev) wrote :

I also would like to be able to either cancel/skip the disk check on boot, or the best option would be to ask users if the disk check can be performed on shutdown, although I know that would require significant changes. Giving users a yes/no choice before performing the disk check is an easy fix, however.

Thiago Teixeira (tvst) wrote :

[cross-posted from bug #3581, which is similar]

In my opinion, the best solution is to make fsck run on *shutdown* rather than on boot-up. The rationale behind this is that people usually turn on their computers to do something with it. At those times, people want their computers to boot up as fast as possible.

Conversely, people usually do not shut down their computer to do something to it. The exceptions to this are when one is going to replace some hardware, or move a laptop around. Other than that, shutdown speed is not as important.

Thus I believe fsck should run on shutdown by default, and there should be an option to change its behavior if the user would prefer that.

Jim Hutchinson (jphutch) wrote :

Another issues that it doesn't check consistently after 30 mounts. In fact, it varies all over the place. Today, mine ran after 21 mounts and it's a fresh install at that. Is there a reason 30 doesn't mean 30? If it's going to run when it feels like it, we definitely need the ability to postpone it.

godog (godog) wrote :

My laptop just hangs while doing the check, and i can not cancel it, so i have no access to my data. There MUST be a way to cancel fsck, it's absolutely necesary. Is not only a matter of wasting time or batery, if disk check fails the computer is totally unaccessible.

godog (godog) wrote :

Well, I used the installation CD to run Ubuntu, modified /etc/fstab/ so it won't run again. Anyway, there shoud be a easier way to cancel fsck.

dahas (bogdan-daja) wrote :

Hi
Fist at all i sow about 4-5 bug reported around de fsck on booting stage.
My point is why fsck dont care of what i set with tune2fs?
This is the way I chose to run or not on booting process.
I sow some 1 propose to wait 10s and give you a choise to stop him pressing CTRL-C or CTRL-D my question is why i chose to wont check tune2fs -c 0 if is ignored :). This is my 10 sec wait and CTRL-C or CTRL-D.
Remember some running servers and day by day the size of disks grow.
To run fdisk on pratition of 10G get 10 min how about on 100G or 1T ?
More if u reboot remote that pc who wait 10 sec for pressing a key to interrupt how you can do that.
So my point is if some 1 wish to run fsck at boot or before reboot it can be done runing a customized script and put him on proper place (boot or shutdown) but i still remain on this fsck to check the settings made by tune2fs witch is the user choise.

Victor Osadci (victor-os) wrote :

Regarding the check-on-shut-down:
It is an interesting idea, but care should be taken in special cases such as UPS initiated shut-down or low battery laptops - it would be awful to lose power in the middle of a fsck.

Another idea would be to have a time-based forced fsck. This should be beneficial to both people that reboot frequently and bump into the forced fsck more often than necessary, and people with impressive uptimes, for whom the 30 mounts could be years without a fsck.

Oliver Gerlich (ogerlich) wrote :

Isn't the forced check already based on time or number of mounts (whichever comes first)? Anyway `tune2fs -i` seems to set the max time between forced mounts.

Victor Osadci (victor-os) wrote :

A value of "0" for the check interval disables the checks.
Something like "tune2fs -c 0 /dev/sda" should disable checks based on mount counts; then is is a matter of "tune2fs -i 1m /dev/sda" to check /dev/sda each month.

Try AutoFsck:

http://wiki.ubuntu.com/AutoFsck

It basically moves this automated 'just in case' check to shutdown and gives you the option not to run it if it's a bad time. There's also a nice simple script (with zenity GUI) on that page which allows you to easily change the interval.

karl (karl-sebastian-liebich) wrote :

but it would be - indeed - a good idea to implement it. It seems to me that this is an issue for many people. And I think solving this is important for making ubuntu presentable to the broad mass and therefore fixing bug #1.

Adam Niedling (krychek) wrote :

The forced check is integrated in the splash screen in Hardy and it is possible to skip it.

Changed in sysvinit:
status: Confirmed → Fix Released
Jim Hutchinson (jphutch) wrote :

This is welcome news and I appreciate the effort. However, so far I haven't had much luck. Pressing esc to skip causes the boot process to freeze and need a reboot. Of course I haven't seen the option in several days so maybe it's been fixed.

Adam Niedling (krychek) wrote :

Hmmm it's another bug that needs another report. I haven't looked for it but i think someone must have reported it already.

spaceman (spacedoubtman) wrote :

YES! I can cancel now

after reading this:
http://<email address hidden>/msg251597.html

basicly:
See man e2fsck.conf(5). Create a file /etc/e2fsck.conf, with the
contents:

[options]
        allow_cancellation = true

Then you should be able to type ^C while it is doing a check, and cancel the fsck.

I vote this should be the default

[quoting spaceman]
basicly:
See man e2fsck.conf(5). Create a file /etc/e2fsck.conf, with the
contents:

[options]
        allow_cancellation = true

Then you should be able to type ^C while it is doing a check, and cancel the fsck.

I vote this should be the default
[/quote]

I second this.

Three and a half years later, I am STILL getting the uncancelable fsck on boot. I have work to do. sometimes it HAS to work NOW and there is NO other option.

PLEASE can we make this the default? You don't have to change the behavior. just print a message "to cancel press ctrl-c". ESPECIALLY on a server, which can be business critical.

karl (karl-sebastian-liebich) wrote :

I consent to that. It is possible to skip fsck when using splash, but is not when not using splash.

If that feature is implemented in usplash it seems to be consens in the community that it is necessary. And if that is the case, users not utilizing usplash should not be excluded...

Reed Meyer (rdm-tripadvisor) wrote :

I also vote that

[options]
        allow_cancellation = true

should be added to /etc/e2fsck.conf in default Ubuntu installations.

I've changed the status from "Fix Released" to "Confirmed" in order to signal the Ubuntu developers that there are several votes requesting this.

Changed in sysvinit (Ubuntu):
status: Fix Released → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.