boot process isn't paused while fsck runs on partition: boot process is completed with fsck running in the background preventing partition from mounting

[Rune K. Svendsen]

Binary package hint: usplash

I had a problem mounting my /dev/sdb1 partition the last couple of times after booting up Ubuntu. I got the following error when trying to mount the partition:

mount: /dev/sdb1 already mounted or /media/data busy

so I tried issuing the following command and I could see that fsck was running in the background, without having notified me, checking /dev/sdb1, and not while showing the splash screen and a progress bar like it usually does:

rune@runescomp:~$ sudo fuser -m /dev/sdb1
/dev/sdb1: 804
rune@runescomp:~$ ps aux | grep 804
root 804 5.0 3.4 72528 71164 ? D 21:29 0:50 fsck.ext3 -a /dev/sdb1

rune@runescomp:~/Desktop$ lsb_release -rd
Description: Ubuntu karmic (development branch)
Release: 9.10

rune@runescomp:~/Desktop$ apt-cache policy usplash
usplash:
  Installed: 0.5.39
  Candidate: 0.5.39
  Version table:
 *** 0.5.39 0
        500 http://archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
Architecture: i386
Date: Wed Sep 30 21:54:05 2009
DistroRelease: Ubuntu 9.10
MachineType: . .
NonfreeKernelModules: kvm_intel kvm fglrx
Package: usplash 0.5.39
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-11-generic root=UUID=55bcb986-d698-4aea-a3bb-c581262ea713 ro quiet splash elevator=deadline
ProcEnviron:
 LANG=en_DK.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-11.36-generic
SourcePackage: usplash
Uname: Linux 2.6.31-11-generic i686
UsplashConf:
 # Usplash configuration file
 # These parameters will only apply after running update-initramfs.

 xres=1920
 yres=1440
dmi.bios.date: 05/26/2008
dmi.bios.vendor: Phoenix Technologies, LTD
dmi.bios.version: 6.00 PG
dmi.board.name: IP35 Pro XE(Intel P35-ICH9R)
dmi.board.vendor: http://www.abit.com.tw/
dmi.board.version: 1.0
dmi.chassis.type: 3
dmi.chassis.vendor: System Enclosure Manufacter
dmi.chassis.version: OEM
dmi.modalias: dmi:bvnPhoenixTechnologies,LTD:bvr6.00PG:bd05/26/2008:svn.:pn.:pvrSystemVersion:rvnhttp//www.abit.com.tw/:rnIP35ProXE(IntelP35-ICH9R):rvr1.0:cvnSystemEnclosureManufacter:ct3:cvrOEM:
dmi.product.name: .
dmi.product.version: System Version
dmi.sys.vendor: .

[Steve Langasek (vorlon)]

Thank you for taking the time to report this bug and help to improve Ubuntu.

Effectively, this is by design; filesystems that aren't required to bring up the desktop should not block the desktop, they should be handled in parallel. However, there's probably a use case for users being able to configure mountall (which is what handles fscks and tells gdm when it's ok to start) to be more strict in waiting for additional filesystems to start up, as well as for mountall feeding progress information via usplash; so reassigning this to the mountall package for Scott to weigh in.

As a workaround, I believe you could change /etc/init/gdm.conf from
  start on (filesystem and ...
to
  start on (stopped mountall EXIT_STATUS=0 and ...

to declare that you don't want gdm to start up until all your drives are mounted. This is not something that should be set as a default in the distribution, however, since it would have adverse interactions for any users who automount network filesystems at boot time.

[nomenquis (philip-lawatsch)]

I'm running into the same problem, however my case is not gdm related.

I've got a dev server system running karmic. On that server I'm mounting about 10 file systems on bootup. On average every 5 boots or so one will have to be checked. Now what happens for me is that the filesystem is simply not mounted and fsckd in the background, while the normal boot process continues.

That means a lot of services are started, even though filesystems that contain data for them are not mounted (yet).

Postfix / mysql et al should not be started until all filesystems have been mounted.

Is there any way to force the boot process to wait until everything has been mounted?

The current way of background fscking will horribly break a lot of server installs imho.

kind regards

[Dave Gilbert (ubuntu-treblig)]

This one caught me out today; I've got a /discs/more that has a chunk of stuff in that got background fsck'd - I don't think this is necessarily a bad idea, but if this is happening then the user needs some notification and an easy way to stop it happening.

Some people might have moved something to a different partition that changes the desktop; e.g. they might have their wallpaper on a partition with just photos on it; or in my case an application I run on the desktop and on a separate partition I have the media files for a music player.

Dave

[Philipp Merkel (plippo)]

I'm just copying my idea from the duplicated bug here so it doesn't get lost:

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]

[Rune K. Svendsen (runeks)]

I agree with the other commenters that this _is_ a nice feature to have,
but the introduction of it seems to introduce a few problems that need
to be fixed in order not to adversely affect the user experience. I will
try to sum up my thoughts on this below.

1. Notification.
First and foremost, the user needs to be notified that a file system
check is in progress. This should happen (in order of importance):
        a) when the user tries to use (mount) the file system (via the
        Places-menu or in Nautilus). As of now, the message that the
        user receives is "mount: only root can mount <dev> on
        <folder>" (I've attached a screenshot). This leaves the user
        wondering what is going on, unless he tries to mount the file
        system via the command line (which _still_, unless the user uses
        the "fuser" command, leaves the user not knowing that fsck is
        what is keeping the file system busy).

        b) (in addition to the above) when the user logs in, via
        notify-osd. A notification could appear saying: <dev> is being
        checked and is not mountable until this has finished. Then, when
        the file system check finishes, a notification could appear
        saying: the file system check of <dev> has finished and it is
        now accessible.

2. Choice.
The (non-advanced) user should be able to cancel the file system check.
This is currently only possible by killing the fsck-process (which, IMO,
will only be done by relatively advanced Linux users).
This, of course, requires the user to know that fsck is what is
preventing him from mounting the file system in the first place (and
probably some command line knowledge as well).

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

Have added a configuration option in the next release, if you put "bootwait" in the fstab options field, mountall will wait for it (though be careful with this, it means your boot will *wait* for this filesystem - so if mountall can't mount it, your boot will fail)

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

Likewise for the things that mountall is builtin to wait for, you can put nobootwait

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

Not sure whether or not that satisfies this bug as "fixed"? (Assuming we have progress notification of those it is waiting for)

[nomenquis (philip-lawatsch)]

Imho just adding the option to turn that behavior off without also making it default will break a huge number of systems upon upgrading to karmic in a very subtle way.

Nobody would expect such strange mount / fsck behavior changes. And this new behavior breaks on almost every server box that mounts user / service data from a different filesystem.
Just imagine a mail server happily accepting (and storing) mail data to /mnt/mail even though /mnt/mail is not really mounted.

I'd honestly love to just have that 'feature' gone, I can't even think of one other OS that does anything close to that. Even windows checks all disks in case it has to befure doing anything else.

Just my 2(euro) cent.

kind regards

[Leon (leonbo)]

I installed 9.10 and when it rebooted it showed a splash screen: the white ubuntu logo.
After that the screen went black and the diskactivity light lighted up. After a couple of minutes it was still doing that. So I pulled the plug on my laptop and fired it up again. I removed the splash and quiet option from grub and booted. I then saw fsck was running.

For me it was a little weird that I didn't receive a message of that so I knew I just had to be more patient.

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

On Mon, 2009-10-12 at 17:53 +0000, nomenquis wrote:

> Imho just adding the option to turn that behavior off without also
> making it default will break a huge number of systems upon upgrading to
> karmic in a very subtle way.
>
We think this is the right default; so we have to turn it off at some
point :-)

Scott
--
Scott James Remnant
<email address hidden>

[Richard Hansen (rhansen)]

On upgrades will "bootwait" be automatically added to the applicable lines in /etc/fstab? If not, would you be opposed to adding that feature?

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

On Tue, 2009-10-13 at 15:21 +0000, a7x wrote:

> On upgrades will "bootwait" be automatically added to the applicable
> lines in /etc/fstab? If not, would you be opposed to adding that
> feature?
>
No, I don't think we want to do that either.

It'd mean that a large portion of users wouldn't be in the default state
anymore.

Scott
--
Scott James Remnant
<email address hidden>

[nomenquis (philip-lawatsch)]

> No, I don't think we want to do that either.

> It'd mean that a large portion of users wouldn't be in the default state
> anymore.

Now, how are you guys planning on informing all the users (and especially admins) about that change in semantics?
I can see potential for quite a big fallout here.

This change should not happen as a surprise for anybody upgrading to a new 'stable' version.

kind regards

[SheVa (sh-vadim)]

>Imho just adding the option to turn that behavior off without also making it default will break a huge number of systems upon >upgrading to karmic in a very subtle way.
>
>Nobody would expect such strange mount / fsck behavior changes. And this new behavior breaks on almost every server box >that mounts user / service data from a different filesystem.

Agree with that 100%. I had the problem on my system when applications started with no input/output filesystems mounted.
This default will break many systems. This cannot be the default.

> After that the screen went black and the diskactivity light lighted up. After a couple of minutes it was still doing that. So I pulled the plug on my laptop and fired it up again. I removed the splash and quiet option from grub and booted. I then saw fsck was running.

Agree with that too. Had the OS misbehaviour too but guessed correctly that the filesystems are being checked.
Some indication for the FS checking should be added

[gerd kainz (kainz-inode)]

I have a similar situation. First drive is relatively small so I decided to administrate users on a second drive. Guess what happens, when you try to login before the check of the second drive finishes. And whats worse there isn't any notification !

+1 for the bootwait option !

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

Could the bootwait option be documented in the release notes?

[Steve Langasek (vorlon)]

Documented at <https://wiki.ubuntu.com/KarmicKoala/ReleaseNotes#Login%20screen%20presented%20before%20optional%20filesystems%20are%20mounted>:

With the new upstart-based boot process in Ubuntu 9.10, the X server will be started, and the login screen launched, as soon as the core filesystems are available. This means that optional filesystems, mounted at locations not required for the system to boot, may not be mounted yet at login time, and may even fail to mount in the case of a filesystem check error.

Users who prefer the previous behavior of waiting for all filesystems to be mounted before launching the login screen can add the bootwait option to these filesystems in /etc/fstab. (439604)

[jarondl (jarondl)]

I won't call this bug fixed until there is some kind of notification that fsck is working on a disk.
Most of my stuff is on a different partition, and not being able to reach it without knowing why is really frustrating.

[Zeniff (zeniffmartineau)]

Hi~
I'm not trying to mount anything at boot, but my problem is that nothing shows up/mounts when I plug in any kind of USB hard drives or flash drives. I typed dmesg and it says there was a removable disk connected, but that's it. I haven't done anything since upgrading from 9.04 to 9.10.

Is this bug related to my problem too?

[SteveLoughran (steve-loughran)]

This has burned me on at least one of the two laptops I've just upgraded this weekend.
http://www.1060.org/blogxter/entry?publicid=BD7025261E678C40A4BF2B225B87893B

One laptop wont come up until I remove the UUID from the root string and insert a hard coded /dev/sda1 string; this may be unrelated. The other, not finding the home disk probably is. It's a big /home dir, and If I can't log in to X then it's considered a problem.

I appreciate what's being attempted here, gives a good experience for those slow, secondary mounts, but I think there are certain partitions that you should pause X for, / and /home being the two I have in mind. These should be given the bootwait attribute on upgrade.

Now, I know it was mentioned in the release notes, so you are free to dismiss as "told you so", but given that neither machine was coming up with X, I wasn't in a position to go through those release notes to see what was in there that I should have remembered.

[Steve Langasek (vorlon)]

On Sun, Nov 01, 2009 at 10:45:07PM -0000, SteveLoughran wrote:
> I appreciate what's being attempted here, gives a good experience for
> those slow, secondary mounts, but I think there are certain partitions
> that you should pause X for, / and /home being the two I have in mind.
> These should be given the bootwait attribute on upgrade.

We *do* block on /home for X.

> Now, I know it was mentioned in the release notes, so you are free to
> dismiss as "told you so", but given that neither machine was coming up
> with X, I wasn't in a position to go through those release notes to see
> what was in there that I should have remembered.

If X isn't coming up, that sounds like the opposite problem: X is still
waiting for /home and /home isn't available. Is that correct?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[SteveLoughran (steve-loughran)]

1. It would be nice to get a list of which things do get blocked for -is there a way of asking mountall itself? I am still trying to understand all of this

2. The root cause was the laptop crashing on resume (unrelated), meaning that an fsck was needed; I think this was delaying stuff. It was exhibiting sometimes as the splash screen bringing up a message under the alert saying "could not mount /home and its UUID", then later on as X not coming up, no /home. All you get is the console. Would the fsck be locking the disck causing X to fall over?

I'm wondering if referencing disks by UUID is causing trouble; on the other machine I couldn't boot with root=UUID=something, editing menu.lst to have root=/sda1 fixed that -again, it shouldn't happen, but it was needed. And no, I don't have quotes around UUID in fstab.

[SteveLoughran (steve-loughran)]

I'm going to add something related to this which is also interesting: if I set bootwait as an attribute for /dev/sda6, the home dir, then the OS hangs at boot time in one of two ways

1. After printing out fsck /dev/sda6 clean it hangs at the console, not crashed, just nothing happening

2. The ubuntu logo appears and then

One or more of the mounts listed in /etc/fstab cannot yet be mounted

/home:waiting for /dev/disk/by-uuid/16165661-0a16-4caa-968a-84e5ea299900
Press ESC to enter a recovery shell

Two possibilities
* the disk isn't coming up
* mount by UUID is failing to work.

(oh, and the recovery shell doesnt come up with I hit ESC, but I consider that a third order problem)

[SteveLoughran (steve-loughran)]

Switching to hard coded paths in the fstab instead of UUIDs, but with bootwait set for /home doesn't mean the system boots either, trace is

fsck from util-linux-ng 2.16
/dev/sda1: clean 237604/1211600 files, 2568587/4883752 blocks (check in 3 mounts)
/dev/sda6: clean 355625/8003584 files, 23000210/31989415 blocks

then nothing, system sits there, keys are echoed, but nothing happens.

[SteveLoughran (steve-loughran)]

-removing the bootwait parameter from /home in fstab does allow the OS to boot again. This implies that adding bootwait to a drive that mountall thinks is should be bootwaiting for

Doesnt work:
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# /dev/sda1
UUID=789e1910-5977-4210-8360-fc84b562aba5 / ext3 noatime,relatime,nodiratime,errors=remount-ro 0 1
# /dev/sda6
UUID=16165661-0a16-4caa-96a8-84e5ea299900 /home ext3 noatime,nodiratime,relatime,bootwait,errors=remount-ro 0 2
# /dev/sda5
UUID=2dd94245-52af-45a8-aae5-fc2c9f14673d none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0
none /proc/bus/usb usbfs devgid=128,devmode=664 0 0

Doesnt work either
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# /dev/sda1
/dev/sda1 / ext3 noatime,relatime,nodiratime,errors=remount-ro 0 1
# /dev/sda6
/dev/sda6 /home ext3 noatime,nodiratime,relatime,bootwait,errors=remount-ro 0 2
# /dev/sda5
/dev/sda5 none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0
none /proc/bus/usb usbfs devgid=128,devmode=664 0 0

does seem to work
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# /dev/sda1
/dev/sda1 / ext3 noatime,relatime,nodiratime,errors=remount-ro 0 1
# /dev/sda6
/dev/sda6 /home ext3 noatime,nodiratime,relatime,errors=remount-ro 0 2
# /dev/sda5
/dev/sda5 none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0
none /proc/bus/usb usbfs devgid=128,devmode=664 0 0

Now, that latter one is the fstab I had at the beginning, the one where sometimes X didn't want to play, I believe, becase home was being fsck'd. I will try and replicate that by queueing up an fsck for the next reboot

[SteveLoughran (steve-loughran)]

correction, that latter one doesnt have the UUIDs, its not the one I had at the beginning, running through some reboots hasn't shown any problems, but I haven't been able to trigger the fsck that I believe set this whole race condition off

[thodpol (thodpol)]

As it is said above, the background checks is a very good feature, but I think it needs some modifications:

--An option to notify users about the locking/checking of the hard drives

--An option to postpone these checks .For example all my developing programs, documents and work are on a secondary 1TB disk-partition and most of the times I need them quickly. the check can last for over an hour.

--what happens when the root/Desktop partition is being checked? There must be an option to postpone the check for a later time as well. There was an incident with the previous release (9.04) that I had to run a demo to some people an I did not remember how to stop the root filesystem check.

--You could have an applet, or a notification with a button that prompts users to schedule the postponed checks for the next restart.

Despite these inconveniences, you should have our congratulations again for this release!

[mdyn (tamerlaha-gmail)]

i've got:
One or more of the mounts listed in /etc/fstab cannot yet be mounted

/:waiting for /dev/disk/by-uuid/16165661-0a16-4caa-968a-84e5ea299900
Press ESC to enter a recovery shell

but if i wait a sec its booting up
how a can fix it?

[Steve Langasek (vorlon)]

That's not a bug; you get a message because your system takes a while to boot, the message is shown deliberately so that you know why the system isn't booted yet.

[SteveLoughran (steve-loughran)]

@thodpol, you should be able to hit ESC during an fsck to skip it, just as before. know that regular fscks are recommended. Indeed, in the Hadoop petabyte filesystem, it likes to read and checksum-verify every block in the distributed filesystem every week, to make sure the data is valid, as well as the directory entry.

I managed to trigger an fsck on /home and this time X did block. Which makes we wonder whether there was some underlying problem the first few times -and more importantly,, is a failure here being handled as well as it could? Trouble is filesystem failures are serious problems, and dropping the end user into a recovery shell is about all you can do consistently; even that requires / and /tmp to be working

[Alain Baeckeroot (alain-baeckeroot)]

 NO filesystem are optional, and the default behavior should be to wait for fsck, and add an option nobootwait for this new feature.

Any real server has its data on additional partitions.

[Alain Baeckeroot (alain-baeckeroot)]

The documentation abotu this new option should appear in * man 5 fstab * too

[Steve Langasek (vorlon)]

This is working as designed, and there is nothing further to be documented in the release notes. Please do not reopen these tasks.

Having this documented in fstab(5) is a fair point, but that manpage is provided by the mount package, not by mountall.

[SteveLoughran (steve-loughran)]

Steve -what about my claim that if you marked a drive that was going to be bootwait only as bootwait in fstab, then the system hangs. I'd view what as something that is not works-as-designed? Have you tried to replicate that with something mounting as /home?

[Steve Langasek (vorlon)]

Please file a separate bug report against mountall for the issue when setting bootwait on a mountpoint that's already waited for.

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

Please file a separate bug report for adding documentation to fstab(5), this one has got too much other detail in it to be useful

[brodiepearce (brodiepearce)]

Nobody has really pointed out that this feature is only going to confuse novice users, which is ultimately the group that Ubuntu is aimed at. A notification on startup at least would be nice so that Grandma Jenkins knows why she can't access anything on her 2nd 'non-essential' drive.

[Twisted Lincoln, Inc. (twistedlincoln)]

@ brodiepearce: I completely agree. While server admins might be expected to be advanced enough to add the "bootwait" option, average users cannot be expected to magically know this, let alone actually do it.

I'd understand taking the position that the new boot process is superior and shouldn't be revereted -- but why on earth would adding the ability to notify the user of the check and provide them an opportunity to cancel it graphically be undesirable?

Perhaps that would need to be added in another package, but if that's the case, the bug should be reassigned to the appropriate package, not just closed with a "too bad for you" message.

[SilverWave (silverwave)]

I would like a notification on log in as to which partitions are being checked.
Also a notification once the check has been completed would be useful.
e.g.
"sdb1 is being checked in the background"
Followed by:
"sdb1 check completed"

Ubuntu empowers users by providing us with the information we need to make informed decisions.
Don't keep us in the dark, rather inform and educate.

[Paul Beardsell (paul-beardsell)]

I don't like this feature and would like the system to WAIT for fsck to finish. bootwait should be the default for local disks.

[hikaricore (hikaricore)]

This is useless.

I have 3 disk scans running in the background at the same time on 3 2Tb drives.
How in the hell am I supposed to know what's going on with them when I can't see status output?

I've added bootwait to these drives but it doesn't help til I reboot....

This is NOT default material in the least.

[Pascal S (pascal.s)]

As reported here https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/496289, the boot process hangs for me if I try to add this bootwait option in the fstab. Does anyone know about a workaround for this problem ?

[SteveLoughran (steve-loughran)]

That link of Pascal to the bug 496289 is the followon bug that hit me. You can't say "bootwait" on your partitions, as then you cannot boot. This can only be corrected by an upstream patch, and they aren't going to on the basis that its mountall that chose to break things, not their code. Their stuff works.

Since "bootwait" doesn't work, nobody is using it. Removing it as an option is not going to introduce compatibility problems. So it is now possible, going forward to

* have some option like "dontwait" purely for those things you don't want to depend on
* test it works
* default to having everything bootwait *and let people add something different for their new filesystems*

The only question then is: patch 9.10, or push this fix out into the next version. For me, its unimportant: I've rolled back to 9.04. I don't like systems that don't boot.

[SteveLoughran (steve-loughran)]

-updated, looked at https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/479965 and that will fix things. Now, is there some way in 9.10 to tell mountall to be strict and wait?

[Steve Langasek (vorlon)]

Pascal,

I notice in bug #496289 you're reporting a rather special case - the problem you're having involves bind mounts, so the underlying device is another directory rather than a block or network device. I think that is probably a separate bug in mountall.

[Steve Langasek (vorlon)]

SteveLoughran,

You *can* say 'bootwait' on partitions, and it does work. bug #496289 specifically talks about mount sources that are not partitions. Do you have a concrete example of this failing for you in karmic?

[SteveLoughran (steve-loughran)]

On Tue, Dec 15, 2009 at 11:00 PM, Steve Langasek
<email address hidden> wrote:
> SteveLoughran,
>
> You *can* say 'bootwait' on partitions, and it does work.  bug #496289
> specifically talks about mount sources that are not partitions.  Do you
> have a concrete example of this failing for you in karmic?
>

I had a laptop that would not boot if I set bootwait=true on / or
/home. I have rolled back to 9.04 and therefore the problem no longer
exists.

[Steve Langasek (vorlon)]

If you had set 'bootwait=true', that's a syntax error; the correct option is simply 'bootwait'.

It's also entirely redundant on the / and /home filesystems. I've heard other reports that setting 'bootwait' on a filesystem where it's already implicit does cause hangs. This is a bug that should be fixed, certainly, but it doesn't mean that bootwait is unusable - there's no reason you should have set bootwait on these fstab entries in the first place.

I guess the original problem you were trying to solve was the issue described at <https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/439604/comments/25>. I think that was indeed an fsck holding up X. And I agree that there should be documentation somewhere of the set of filesystems that mountall implicitly waits for.

[PsYcHoK9 (psychok9)]

Same bug here with an Acer 5920G and secondary ext3 partition. It doesn't display any warning to the user.

[Rockney (rockney8588)]

The "bootwait" option is dodgy at best. Seems to have many gotchas depending on the specific hardware configuration (does not work on any of 3 systems here, all different). This behavior BREAKS many existing systems causing untold loss of thousands of human hours. Further, it does not seem to be fully thought out because if it were it wouldn't break so many systems. Lastly it is not obvious and is especially bad for newbies.

The only reasonable conclusion is to revert to the previous stable and predictable behavior until this so-called "feature" can be introduced without breaking systems and wasting people's time.

btw - My short-term solution was to warp /etc/init/mountall.conf and remove the --force-fsck and --fsck-fix options from the "exec moutall" line. Ya - you must pay attention and run fsck by hand accordingly ... but at least I know when it's being done and the rest of the system isn't crashing all over the place because it does have the mounts it needs!!

[Jochen Topf (jochen-remote)]

I totally have to agree with Rockney comment above. It was a bad idea to introduce this change. Just cost me hours to find out what was wrong with a production server and I still have no fix. Using the bootwait option does not work, because the mount command doesn't know about this option. Breaking hundreds of thousands of systems is not acceptable. This changes has to be reverted!

[Eric Marceau (ericmarceau)]

Above, Steve Langasek (vorlon) wrote on 2009-10-10:

     "Effectively, this is by design; filesystems that aren't required to bring up the desktop should not block the desktop, they should be handled in parallel."

My boot disk partition is DB001_F1, which contains the system files and ${HOME} directory.

However, my installation is configured such that the all the other directories under the ${HOME} directory are on a second partition, namely

     Desktop -> /DB001_F2/home/ericthered.Desktop

Not every time, but often enough, when I do a pushbutton boot (cold) or a warm boot (restart), it appears that the system mounts the ${HOME} directory as if it were my Desktop, and I have to rebuild my Desktop from scratch (please don't ask me the steps, because I always have to muddle thru to get it back to how I want it.

Is there some setting, configuration or switch that I can set to force the boot process to wait until it can access all disks properly, BEFORE it attempts to build the GDM environment ?

System: Host: OasisMega1 Kernel: 5.4.0-67-generic x86_64 bits: 64 Desktop: MATE 1.24.0
           Distro: Ubuntu 20.04.2 LTS (Focal Fossa)

Machine: Type: Desktop Mobo: ASUSTeK model: M4A78-E v: Rev 1.xx serial: 101048580000313
           BIOS: American Megatrends v: 2603 date: 04/13/2011

CPU: Quad Core: AMD Phenom II X4 810 type: MCP speed: 800 MHz min/max: 800/2600 MHz

Graphics: Device-1: AMD RS780D [Radeon HD 3300] driver: radeon v: kernel
           Display: server: X.Org 1.20.9 driver: ati,radeon unloaded: fbdev,modesetting,vesa
           resolution: 1440x900~60Hz
           OpenGL: renderer: AMD RS780 (DRM 2.50.0 / 5.4.0-67-generic LLVM 11.0.0) v: 3.3 Mesa 20.2.6

Info: Processes: 248 Uptime: 24m Memory: 2.92 GiB used: 1.24 GiB (42.5%) Shell: bash inxi: 3.0.38

 Filesystem Size Used Avail Use% Mounted on

 /dev/sdb3 192G 16G 167G 9% /

 /dev/sdb7 289G 153G 122G 56% /DB001_F2
 /dev/sdb8 289G 246G 29G 90% /DB001_F3
 /dev/sdb9 289G 258G 17G 95% /DB001_F4
 /dev/sdb12 193G 29G 154G 16% /DB001_F5
 /dev/sdb13 193G 149G 35G 82% /DB001_F6
 /dev/sdb14 289G 166G 109G 61% /DB001_F7
 /dev/sdb4 92G 35G 53G 40% /DB001_F8

 /dev/sdc2 99G 60M 94G 1% /site/DB003_F1
 /dev/sdc3 357G 67M 338G 1% /site/DB003_F2

 /dev/sda2 108G 7.0G 96G 7% /site/DB004_F1

Thank you.

[Steve Langasek (vorlon)]

This is a very old bug report and mountall is no longer part of the Ubuntu boot process on any supported Ubuntu desktop releases. It is therefore not constructive to ask your question here. Please either file a new bug report if you believe there is a bug in Ubuntu, or ask your question in one of the various Ubuntu support forums such as AskUbuntu.