Startup in Karmic with unclean filesystems leaves system in a wrong state

[Sven Boden]

With Karmic when you start up with previously unclean file systems, the fsck for these filesystems seems to happen in the backgound while the startup continues on. So you can be in a state where you are able to login but the system can't find the home directory e.g. (as I put those on a separate filesystem). This is very annoying, when filesystems are unclean the system should first fsck them and wait until all required filesystems are mounted.

The workaround is to boot in safe mode, drop to the shell, wait until the fsck is ready, and then usually startup X yourself.

Error messages:
When booting via the workaround after you drop to the shell... if you then do a "mount -a" you get something as:
    mount /dev/sda5 already mounted or /media/sda5 busy
If you then check with "fuser /dev/sda5" you see something as follows being executed:
    fsck.ext3 -a -C 11 /dev/sda5

I tried this out on a newly installed Karmic system, without any additional configuration changes. In my view whenever the system finds an unclean filesystem it should make sure it's clean (and mounted) before continuing.

[Gabe Gorelick (gabegorelick)]

Why is dropping to a shell a good solution? Doesn't the fsck eventually finish and then you can access your separate partition? It seems much better to give the user a fast boot and most of their desktop (sans corrupted home directory) than to just give them a shell with no home directory.

[Sven Boden (svenboden)]

If I drop to the shell I can let the fsck finish and start the X environment manually (just as a work around).

If I don't do anything I can login via the GUI, but since my home directory is "not ready" by then I just get an empty desktop and a warning dialog like "cannot access home directory, taking / as default". After which the session is pretty unusable of course, default installation is that most of the desktop is in the home directory.
I also do not get an indication on the login screen that something is not ok (that something is still running in the background)

[Martin Rehn (minpost)]

Is this behavior really by design? If so, it is a very bad one. By default, the system should wait until all file systems are available before letting the user log in. Otherwise, the user can suffer data loss as follows:

1) Boot with unmounted file systems. The mount points will look like empty directories.
2) The user logs in.
3) Program X starts up and finds that expected data Y is missing.
4) Program X proceeds to perform cleanup or initialization based on data Y having disappeared.

Data loss has now already occurred in the case when program X writes to a different file system than where Y is located. For instance, if the home directory was mounted, but not the file system that contains my digital photos, a photo manager will now clear out metadata about the supposedly deleted pictures from its database. Some programs will ask the user first about this, but as is well known the user always answers "yes".

Otherwise:

5) The missing file system is mounted.
6) Program X keeps writing a clean slate of data in the location of Y, oblivious to the fact that it is now overwriting the real data, which has suddenly reappeared.

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

From the bug description, this sounds like an issue with the karmic mountall where it would continue when it shouldn't - this has been fixed in Lucid