"bootwait" in fstab causes mount problems

[Dylan]

Binary package hint: mountall

The Karmic release notes and bug #469604 suggest adding "bootwait" as an option in fstab (presumably /etc/fstab) if there is a need to ensure that any fsck is done before the system opens to users.

Now, I'm probably missing something, but if I add "bootwait" in /etc/fstab, I cannot mount the relevant parition. See below for jfs. Have also had this with ext3.

~$ sudo vi /etc/fstab
[added bootwait option]
~$ grep bootwait /etc/fstab
LABEL=Myth2 /media/md2 jfs defaults,bootwait 0 2
~$ sudo umount /media/md2
~$ sudo mount /media/md2
mount: wrong fs type, bad option, bad superblock on /dev/sdd1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail or so

~$ sudo vi /etc/fstab
[remove bootwait option]
~$ grep bootwait /etc/fstab
~$ grep /media/md2 /etc/fstab
LABEL=Myth2 /media/md2 jfs defaults 0 2
~$ sudo mount /media/md2
~$

Now, although mount is reporting this error, I'm suggest this is a mountall problem as the instruction to do this comes from mountall, and mountall is the new kid on the block.

Description: Ubuntu 9.10
Release: 9.10

mountall:
  Installed: 1.0
  Candidate: 1.0
  Version table:
 *** 1.0 0
        500 http://mirror.internode.on.net karmic/main Packages
        100 /var/lib/dpkg/status

mount:
  Installed: 2.16-1ubuntu5
  Candidate: 2.16-1ubuntu5
  Version table:
 *** 2.16-1ubuntu5 0
        500 http://mirror.internode.on.net karmic/main Packages
        100 /var/lib/dpkg/status

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

We probably need to patch util-linux's mount to ignore the bootwait, nobootwait and showthrough options ;-)

[Alain Baeckeroot (alain-baeckeroot)]

It would be better to follow Ubuntu/Canonical policy to work with upstrean (as recommended by M.Shuttleworth himself) and to have the changes integrated in the package, with adequate documentation in the manpages.

[Alain Baeckeroot (alain-baeckeroot)]

see also https://bugs.launchpad.net/debian/+source/upstart/+bug/490746

[Alain Baeckeroot (alain-baeckeroot)]

How importance "LOW" ?

Are you mad ?
Currently servers boot without waiting for all partitions , and this cannot be fixed, even by adding ugly workaround in fstab.

Mounting filesystems and /etc/fstab are not toys for kids. This is CRITICAL

[Al Williams (wd5gnr)]

In my case, I am affected by this with a separate /home and /tmp partition. I would think you could assume that things like /home /usr and /tmp... maybe even /opt ought to hang the boot process. I grant you, if you have /big-movies or something maybe that would be ok.

But certainly at least gdm/kdm (kdm in my case) ought to do something graceful when /home is empty instead of trying to start up on / which is not a good idea.

[Alain Baeckeroot (alain-baeckeroot)]

This is a mountall bug.
mountall need to be fixed properly, and not mess-up fstab.

[Pascal S (pascal.s)]

I am not sure it is the same problem, but when I add "bootwait" in fstab for my data (which is not /home) partition, the system won't boot at all, it hangs somewhere during the process. Considering my configuration, this bug is blocking for me.

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

For lucid, we've reverted to again waiting for all filesystems so the bootwait option has been removed (all fstab entries act as if it was there).

Leaving this bug open to remind me that there's still the "showthrough" and "optional" options that util-linux's mount should ignore (generally only used for the built-ins which aren't listed in /etc/fstab, but worth having full coverage)

[Pascal S (pascal.s)]

Good news for Lucid, but in the meantime what is the solution with Karmic to have a system that waits for my filesystems to be checked ?

[Steve Langasek (vorlon)]

Scott,

Waiting for all filesystems is a problem for anyone:

 - who uses NM to bring up their network at login time and has a network filesystem configured in /etc/fstab
 - who has an old and no longer applicable fstab entry that they haven't cleaned up
 - who has a custom fstab entry for any sort of removable media that isn't guaranteed to be present at boot time

I realize that the implementation of 'bootwait' has been rocky in karmic, but eliminating it will introduce a whole different set of regressions, some of which users will *not* be able to sensibly work around with anything nearly so simple as adding an option in /etc/fstab. Please reconsider this mountall change.

[Alain Baeckeroot (alain-baeckeroot)]

We don't ask to wait for all the possible partitions

We ask for :
- no errors due to _UNDOCUMENTED_ bootwait option in /etc/fstab
- waiting for _LOCAL_ filesystem until fsck is finished at least a message in a popup or CTRL-C to interrupt fsck ala debian old-fashion. It is the user responsability to vreak havoc in his system at boot time, not ubuntu's.

no more, no less :-)

[Launchpad Janitor (janitor)]

This bug was fixed in the package util-linux - 2.16-1ubuntu6

---------------
util-linux (2.16-1ubuntu6) lucid; urgency=low

  * mount/fstab.5: document the bootwait, nobootwait, showthrough
    and optional mount options accepted by mountall.
  * mount/mount.c: don't pass the above options to mount(). LP: #479965.
 -- Scott James Remnant <email address hidden> Wed, 23 Dec 2009 04:29:48 +0000

[Adam Funk (a-funk)]

Is util-linux going to be fixed in karmic too?

[gumpish (launchpad-5-gumpish)]

Guess not. Apparently people encrypting their disk are so far from mainstream that it just doesn't make business sense to support those users of the current release.

[Steve Langasek (vorlon)]

This change has nothing to do with disk encryption.

[Jochen Topf (jochen-remote)]

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!

[glinsvad (glinsvad)]

> This bug was fixed in the package util-linux - 2.16-1ubuntu6

I just want to point out that this means it hasn't been fixed for Karmic which is on 2.16-1ubuntu5 - am I right? Any chance of backporting the fix?