fsck of non-fhs filesystem continues during boot

[Philipp Merkel]

Binary package hint: mountall

When I booted into karmic today, a routine drive check of my data partition (ext3 formatted) was started. The message "... has been booted ... times without being checked, check forced" was shown, but the boot process just continued, xsplash and then gdm appeared and I could log in, just to find out that I could not mount my data drive because it was "busy or already mounted". I realized that the fsck process was still running, but I didn't find any output of it on any VT.

Expected:
The system should wait for the check to finish before continuing the boot, leaving me a chance to cancel it, as it has been in jaunty.

I hope this is the right package to report this bug.

ProblemType: Bug
Architecture: i386
Date: Wed Oct 7 10:02:36 2009
DistroRelease: Ubuntu 9.10
Package: mountall 0.1.8
ProcEnviron:
 PATH=(custom, user)
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-11.38-generic
SourcePackage: mountall
Tags: ubuntu-unr
Uname: Linux 2.6.31-11-generic i686
XsessionErrors:
 (gnome-settings-daemon:2355): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (gnome-settings-daemon:2355): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (polkit-gnome-authentication-agent-1:2492): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (gnome-panel:2467): Gdk-WARNING **: /build/buildd/gtk+2.0-2.18.1/gdk/x11/gdkdrawable-x11.c:952 drawable is not a pixmap or window
 (gnome-power-manager:2481): Gdk-CRITICAL **: gdk_window_thaw_toplevel_updates_libgtk_only: assertion `private->update_and_descendants_freeze_count > 0' failed

[Scott James Remnant (Canonical) (canonical-scott)]

This is actually deliberate.

Because it's on a separate disk, this shouldn't slow the boot down.

[Philipp Merkel (plippo)]

I don't know if I understand your comment (and the change of the title) correctly. So you mean the boot should continue, but the check should be cancelled when the boot has finished? It's taking quite a long time, five minutes or so, so it will never be finished during the boot time. But why then start it in the first place?

[Scott James Remnant (Canonical) (canonical-scott)]

On Sat, 2009-10-10 at 18:04 +0000, Plippo wrote:

> I don't know if I understand your comment (and the change of the title)
> correctly. So you mean the boot should continue, but the check should be
> cancelled when the boot has finished? It's taking quite a long time,
> five minutes or so, so it will never be finished during the boot time.
> But why then start it in the first place?
>
The check should be carried on in the background while your desktop is
up, the path is assumed to be a non-critical one (it's under /mnt
or /media? :)

Scott
--
Scott James Remnant
<email address hidden>

[Philipp Merkel (plippo)]

Ah, I understand, thank you for the explanation. In my case, it's mounted to /home/me/data (in fstab). So sure, this is not really a critical path for the system, but it is for the user and at first I was quite surprised that the folder that should contain all my data was empty and I also couldn't mount it manually. Fortunately I remembered the message about the check, but if I hadn't seen it, I (and I gess most users) would have been quite helpless - especially because if I had rebooted before the check was finished, it would have started again at the next boot.

In general, I find it a good idea to check non-critical drives in the background, but the user should be informed and have a possibility to cancel the check. In the ideal case, when a drive can not be mounted because it is currently checked there maybe should be a message (after login for a drive in the fstab or when the user tries to mount it for other drives) - like:

/mnt/... is being checked right now and cannot be mounted yet.
[Cancel check and mount] [Wait until it's ready]

But I suppose it's to late for something like that to be added in Karmic...

[Steve Langasek (vorlon)]

This is the same as bug #439604; marking as a duplicate.

[Steve Langasek (vorlon)]

(please also see the master bug for a possible workaround if you don't like the default behavior)