mountall ignores nofail mount option

Bug #610869 reported by Artem
158
This bug affects 28 people
Affects Status Importance Assigned to Milestone
mountall (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

Binary package hint: mountall

mountall ignores nofail mount option. Ubuntu can not be started if external sas device is down, for example.

Description: Ubuntu 10.04.1 LTS
Release: 10.04, 10.10, 12.10, 14.04

Revision history for this message
Konstantin Khlebnikov (khlebnikov) wrote :

Ubuntu 10.10 Maverick. The bug is still there.

possible workaround: using option "nobootwait"

Revision history for this message
Eric Bertrand (ebertrand) wrote :

Thanks Konstantin.

I was having the same problem and that solved it.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in mountall (Ubuntu):
status: New → Confirmed
Revision history for this message
Bryan C. Hinson (bryan-hinson) wrote :

Ubuntu 10.11 Oneiric. The same fstab line that worked in 9.04 Jaunty for an external usb hard drive would give disk checking errors at boot in 10.11. "nofail" didn't change the behaviour, but "nobootwait" solved the problem. Thanks for your posts.

Revision history for this message
Tim Gehpunkt (rollercoaster) wrote :

Using "nobootwait" is not an option to me, because "nobootwait" also causes the system not to wait for the filesystem to be checked.
In other words, the fsck is run in background while the boot process continues.
This causes other services that depend on that fs to fail.

Also "optional" (mentioned in fstab man page) does not work as expected, it also causes Plymouth to stop the boot process and to display the S&M message.

I just need an option that causes the boot to continue if a (external USB) device is removed and not to display stupid messages on the console where no display and no keyboard is connected.

Revision history for this message
Tim Gehpunkt (rollercoaster) wrote :

"Yust wait long enough, someone will send a patch"

Ok, so after 1.5 years here is my solution for the problem. "nofail" wasn't implemented at all, though it is
documented. Geee...

patch may have side effects but does what it should. Ah and it is against mountall 2.15.3 from Ubuntu 10.04.
I don't write "LTS" by intention, because it seems to be completely unsupported.

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "reel-mountall-nofail.diff" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
Revision history for this message
Brian Murray (brian-murray) wrote :

Thanks for taking the time to submit a patch! I was able to get the patch applied to the Precise (what will be 12.04) version of mountall. However, the behavior is not what I had expected nor what I think you intended. Instead of seeing a message regarding the skipping of the filesystem marked nofail I saw the 'disk drive is not ready or present' error and had the skip or manual prompt. That quickly went by and then the system booted.

I think instead the message you intended should be displayed and then the system should continue booting. I'd be happy to review any more patches and help get them uploaded. Thanks again.

Changed in mountall (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → High
Revision history for this message
kay (kay-diam) wrote :

Ubuntu 12.04 has been released, but nofail still doesn't work.

Please fix it!

Revision history for this message
Steve Langasek (vorlon) wrote :

The 'nofail' option is documented as:
   do not report errors for this device if it does not exist.

The problem you're describing is not one of reporting errors, but a lack of timeout while waiting for a device to become available on boot. 'nofail' is not a correct option to use for this.

mountall does support a 'timeout' option which can be set instead, which I believe is what you want. by default this gives a timeout of 30s (globally configurable as an argument to mountall).

This option is not documented in the fstab manpage, which is a bug. Reassigning to the mount package for this.

affects: mountall (Ubuntu) → util-linux (Ubuntu)
Changed in util-linux (Ubuntu):
importance: High → Medium
Revision history for this message
Ivan Frederiks (idfred) wrote :

Are you sure? I need 'nofail' option to use my external hdd with my laptop. Sometimes hdd remains plugged in for a week and sometimes I take my laptop away and I want it to continue booting normally.
In this regard I think that documentation of 'timeout' option should be a separate bug.

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 610869] Re: mountall ignores nofail mount option

On Sat, May 19, 2012 at 08:46:03AM -0000, Ivan Frederiks wrote:
> Are you sure?

Yes.

> In this regard I think that documentation of 'timeout' option should be a
> separate bug.

There's only one bug here, which is the lack of documentation of 'timeout'.
The 'nofail' option is not defined to do what you want, and we don't use it
in mountall.

Revision history for this message
ill (illumilore) wrote :

From reading the documentation, noauto option would mean that it will not auto mount at boot up but will still automount if present/detected (since cdroms and floppies use this and are automounted)? I tried the timeout option, but that doesn't seem to work. Do you have a syntax example?

Revision history for this message
Steve Langasek (vorlon) wrote :

The timeout option should be just a number of seconds to wait for the device before giving up on it, e.g. timeout=60. What's the fstab line that you tried and found didn't work?

Revision history for this message
Jamin W. Collins (jcollins) wrote : apport information

ApportVersion: 2.0.1-0ubuntu8
Architecture: amd64
DistroRelease: Ubuntu 12.04
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
NonfreeKernelModules: nvidia
Package: util-linux 2.20.1-1ubuntu3
PackageArchitecture: amd64
ProcEnviron:
 TERM=xterm
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 3.2.0-25.40-generic 3.2.18
Tags: precise
Uname: Linux 3.2.0-25-generic x86_64
UpgradeStatus: Upgraded to precise on 2012-04-27 (54 days ago)
UserGroups: adm admin cdrom dialout libvirtd lpadmin plugdev sambashare

tags: added: apport-collected precise
Revision history for this message
Jamin W. Collins (jcollins) wrote : Dependencies.txt

apport information

Revision history for this message
Jamin W. Collins (jcollins) wrote :

I'm looking to do the exact same thing as the original reporter. I have some partitions on a secondary drive that is not always connected to my system. If the secondary drive is present at boot I would like the partitions mounted, if it is not, I would like the system to continue without any notice or prompting. Like the original reporter, I first tried the nofail option, which was ignored. I then found this report. I've tried the timeout option but it too appears to be ignored and receive the following prompt for each partition:

The disk drive for $path is not ready yet or not present.
Continue to wait, or Press S to skip mounting or M for manual recovery.

Relevant line from fstab:

UUID=651dbe1c-234c-4cec-923c-8b05184beda2 /opt/vms ext4 defaults,timeout=1 0 2

Revision history for this message
Jamin W. Collins (jcollins) wrote :

moving back to mountall as timeout option does not appear to work

affects: util-linux (Ubuntu) → mountall (Ubuntu)
Revision history for this message
Ivan Frederiks (idfred) wrote :

@Steve Langasek
Looks like you misunderstood us.

> The 'nofail' option is documented as:
> do not report errors for this device if it does not exist.

> The problem you're describing is not one of reporting errors, but a lack of timeout while waiting for a device to become available on boot. 'nofail' is not a correct option to use for this.

When 'external sas device is down' or 'drive is not always connected' the device does not exist (and most probably would not become available in close future) and we want to suppress any errors related to this fact. In this case 'nofail' option seems to fit perfectly.

Revision history for this message
Steve Langasek (vorlon) wrote :

I don't think I've misunderstood anyone here, though I may have misunderstood the code. Also, I don't think everyone commenting on this bug report actually has the same goals.

There are three orthogonal aspects of boot behavior that users may wish to configure here.
 - whether to hold up the boot waiting for a device (nobootwait/bootwait)
 - how long to wait for the device before concluding it's not going to show up ("timeout=n" in theory... in practice, timeout + --dev-wait-time=N)
 - what to do if a waited-for device hits the timeout: throw an error, or continue without? ("nofail", in theory)

So a more careful inspection of the code shows me that 'timeout' doesn't directly do anything useful; all it does is cause an event to be emitted, it doesn't interact with 'nofail' at all or otherwise allow the boot to proceed noninteractively if the device is absent.

In theory, what you *could* do with the existing functionality is create a job which is 'start on device-not-ready MOUNTPOINT=$MOUNTPOINT' and calls 'mntctl change-mount none $MOUNTPOINT'. E.g.:

  start on device-not-ready MOUNTPOINT=/opt/vms
  exec mntctl change-mount none $MOUNTPOINT

But when I test this I get an assertion failure from NIH. So I guess this code hasn't been adequately tested. Anyway, I wouldn't recommend this as the right way to do this, but was hoping to be able to offer it as a workaround.

Revision history for this message
Jamin W. Collins (jcollins) wrote :

So, this leaves the question of what needs to be done to allow for a storage volume for which it is normal for it to be either present or not present. If it is present, have it mounted as part of the normal startup process. If it is not present, simply continue on with the normal boot process without any delay or manual action.

Does a wishlist, feature request, bug report, etc need to be filed? If so, which package should it be against? I don't this this is a very abnormal use case.

Revision history for this message
Dainius 'GreatEmerald' Masiliūnas (pastas4) wrote :

I agree with comment #21. This is an important feature, and it's strange that it hasn't been implemented yet. The expected behaviour should be:
- If device can be mounted, mount it.
- If device can't be mounted, skip it (also possibly log the event somewhere).
- Optionally allow for specifying time for the device to go online.

In my case, it would be very useful in cases when you have to use an external partitioning tool to change some non-essential partition on your disk - right now it just fails to boot, leaving you with very primitive tools to make it boot again without that partition being mounted.

Revision history for this message
V字龍(Vdragon) (vdragon) wrote :

Affected by this issue, and same as reporter I expected 'nofail' option as the solution

My situation is I had my system on a ssd and while I want to automount other system on my own computer I also want system to skip it if I boot my ssd on another computer.

Revision history for this message
V字龍(Vdragon) (vdragon) wrote :

s/system/file system/g
sorry about that

description: updated
description: updated
Revision history for this message
YAMAMOTO Hirotaka (ymmt2005) wrote :

This affects 14.04 too.

description: updated
tags: added: trusty
removed: precise
Revision history for this message
Mario (q-mario) wrote :

Also affected by this on trusty! In my case somehow the message to skip is showing up when mounting an LVM over LUKS over LVM partition however the boot continues fine without any interaction... would be good to get rid of that failure

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.