no visible indication that a long-running fsck is taking place in background

[Matthew Vermeulen]

If a filesystem check is forced on bootup, usplash will drop out of graphical mode and drop to a text mode. This is not very friendly for first time users.

Usplash should instead display a visible indication that a Disk Check is being performed, and use the progress information extracted from fsck itself. Currently this information is provided on a filehandle from the low-level fsck process, but the high-level fsck process does not pass status information through (beyond displaying a text status-bar), or send the status to usplash.

The front-end fsck should be modified so that the status information is passed to a 'usplash_write' command and the currently active progress bar be hijacked or borrowed.

[Matt Zimmerman (mdz)]

This is intentional, because usplash cannot display progress for fsck. If it continued to display, there would be no indication of activity and the boot process would appear to be stalled.

[Jonathan Austin (mailforwho)]

Sometimes this is exactly what happens to me - it is checking the filesystem but there is no progressbar - so it looks like it has crashed.

[Paul Sladen (sladen)]

who: it uses a timeout; if the fsck finishes before the timeout expires then you'll only ever see the graphical display; it's only when a fsck takes longer than the usplash timeout that it will drop out of graphical mode to allow you to see the detailed information. (It's a form of safe fallback).

[Didier Raboud (odyx)]

Usplash should be in some way "warned" of a fsck and display a status bar for it, to have a display of the check and the user "graphically" informed of the check.

[Bruno Santos (bsantos)]

This still happens to me on edgy. :(

[Jens (jens-launchpad-net)]

How long is the timeout for usplash to go, and where is it configured? I have a 400G partition (ReiserFS) that gets checked on boot and it always goes back into text mode there. I would like to make this delay longer.

See also Bug 67453.

Jens

[Bruno Santos (bsantos)]

I have two 250G ReiserFS partitions and 60 seconds timeout has been
enough.

Add to /etc/init.d/checkfs.sh:

usplash_write "TIMEOUT 60"

Bruno

On Fri, 2006-11-03 at 12:50 +0000, Jens wrote:
> How long is the timeout for usplash to go, and where is it configured? I
> have a 400G partition (ReiserFS) that gets checked on boot and it always
> goes back into text mode there. I would like to make this delay longer.
>
> See also Bug 67453.
>
> Jens
>

[Michael (michaeljt)]

Some filesystem checkers (notably for ext2, which most newbies will be using) do give progress information. If such a checker is being run, usplash could monitor the information which it sends and show a status bar, and only go into text mode if something unexpected happens (or it receives no information within a certain timeframe). It could also go back in to graphics mode after fsck is finished (or even display the information in a window, like the Fedora usplash).

[Kyromaster (kyromaster)]

Displaying it in a window like in fedora would be the nicest idea IMHO

[towsonu2003 (towsonu2003)]

Can we change the importance? it sounds now much more like a bug than a feature and it affects everyone... thanks :)

[Matthew Whitworth (mwhitworth)]

Yeah, when fsck is run (after a bad shutdown), I get no visible feedback at the 'Checking filesystems' stage, so I tend to restart after x minutes, and it's fine. A text-mode fsck is intimidating for first-time users. I consider this to be a bug.

[Michael (michaeljt)]

The following may sound like a very naive suggestion, but I will make it anyway. Usually fsck is run routinely every 30 (or so) times a file system is mounted. Is there any reason why fsck can not instead be run in the background in read-only mode every so often while the system is running? This will produce a number of false positive errors due to temporary inconsistencies in the file system. However, it should also confirm that 99% of the file system is consistent. Then, when fsck is run at start up, it need only check those previously reported errors to make sure that they have gone, which should be much faster. This could even be short-circuited further by comparing the errors on different live runs and eliminating those which have disappeared since the last run.

[Michael (michaeljt)]

Or as an alternative form of my last comment, do a live scan on every boot (or every second, third or whatever) and set a maximum number of times a given error can appear before a full scan is forced on the next boot.

[Robert Hrovat (robi-hipnos)]

I vote for this thing. It should be fixed somehow!

When fsck starts in the background after boot, users usually press reset button after few minutes because they think machine is frozen and complains about slow machine startup

[tuxo (beat-fasel)]

This bug is flagged as wishlist, however, it is serious regarding how non-linux savy people react to it. When an fsck happens, most people think the machine has frozen on them and press the reset button, just to fall back to the black command prompt on the next startup. As a short term solution, I would suggest to provide at least a feedback to the user to be patient and showing a graphical progress bar in the same style as the graphical boot screen. Like this the user knows that the machine has not crashed but is doing maintenance work.

[NoWhereMan (e.vacchi) (uncommonnonsense)]

there are some scripts on the forum and the wiki which allow you to skip scan on next book or just force the scan on *shutdown*.

I think the shutdown thing is a clever idea, you usually want the system up & running quickly, but you don't (or shouldn't, IMO) mind if shutdown will take longer as if you are shutting down you're already done with your work.

bye

[Tonic Artos (tonic)]

The simplest solution is to have checkfs changed to tell usplash a filesystem check is taking place. Then the Usplash theme could do whatever is appropriate to inform the user. Some message plus throbber would be good. In the long term Usplash will need to read a FD for fsck progress display - for fscks that support it.

[Jonathan Musther (musther-deactivatedaccount)]

AutoFsck moves the periodic fsck to shutdown, and checks with the user whether it's a good time to run.
http://wiki.ubuntu.com/AutoFsck

[Michael (michaeljt)]

Jonathon: looks interesting. I will put my question to you again (are you an fsck expert?) Do you know whether it would at least in theory be possible to run part of fsck on a live filesystem, and only to run the rest at boot/shutdown time? I am thinking of something like the following: fsck runs in the background in read-only mode on the file system, while the user is doing other work. Due to the fact that the filesystem is in use, certain errors will be flagged which are not in fact errors. Next time fsck runs on boot/shutdown, it only does a limited check to see whether the errors which it picked up during its live run are really errors or just false positives.

I could imagine that some (but not all) types of fsck errors could be sensibly screened for in this way, but then again, I am not an expert, and do think that someone might have implemented this if it were really as simple as I picture it.

[Martin Pitt (pitti)]

This is fixed in hardy for all non-root partitions already (see https://wiki.ubuntu.com/DesktopTeam/Specs/PartitionManagement). I'll shortly add this usplash fsck integration for the root file system, too. There is a case where it causes damage, I want to track this down first.

Feedback appreciated!

[Launchpad Janitor (janitor)]

This bug was fixed in the package sysvinit - 2.86.ds1-14.1ubuntu36

---------------
sysvinit (2.86.ds1-14.1ubuntu36) hardy; urgency=low

  * debian/initscripts/etc/init.d/checkroot.sh: Use usplash fsck integration
    as well, but restrict it to ext2 and ext3. Other file systems do not
    provide progress information anyway, nor do they do regular checks of
    clean file systems, and especially reiserfsck does not seem to like
    getting backgrounded. (LP: #38303)

 -- Martin Pitt <email address hidden> Tue, 19 Feb 2008 11:02:49 +0100

[satkata (satkata-deactivatedaccount-deactivatedaccount-deactivatedaccount)]

I have formatted my partitions with reiserfs.
Should I expect then, that the upgrade to hardy wont fix it, as described above?

Should then rather add a startup script like this:
/etc/rcS.d/S29usplash_timeout.sh

#!/bin/sh
/sbin/usplash_write "TIMEOUT 60"

I have read this in the following duplicate bug
https://bugs.launchpad.net/ubuntu/+source/usplash/+bug/22658

[Martin Pitt (pitti)]

Right, reiserfsck does not provide any useful machine readable progress report, so we cannot integrate it into usplash.