mountall passes bad arguments to /sbin/mount.aufs

Bug #431954 reported by Test-tools on 2009-09-17
This bug affects 2 people
Affects Status Importance Assigned to Milestone
aufs (Ubuntu)
mountall (Ubuntu)
Scott James Remnant (Canonical)
Scott James Remnant (Canonical)

Bug Description

Binary package hint: mountall

after getting somehow to boot, getting also aufs to mount via "mount -a",
I get following on stderr(!) with: sudo mountall -a >/dev/null

/sbin/mount.aufs: Bad arg. -f -o rw,br:/.filesystems/usr/overlay=rw:/usr=ro
mountall: mount /usr [11110] terminated with status 1

fstab line is:
aufs /usr aufs br:/.filesystems/usr/overlay=rw:/usr=ro 0 0

Ubuntu karmic, mountall 0.1.6

(By the way, mountall --version wrongly displays
mountall 0.1.0
Copyright (C) 2009 Canonical Ltd.

Roland "Test-tools" Bär

Test-tools (roland-verifysoft) wrote :

It was: mountall -v (now -a ..)

Test-tools (roland-verifysoft) wrote :

It was: mountall -v (not -a ..)

Hmm, I wonder whether it's the -f or the -o it doesn't like.

Surprised mount is calling it with -f (which means "fake it")

Test-tools (roland-verifysoft) wrote :


it is -f it doesn't like. At that place, -o is expected.
Have a look to the script /sbin/mount.aufs

Roland "Test-tools" Bär

I'm half-inclined to say that this is a bug in mount.aufs, it should support the -f option as it's something that mount will pass

Changed in mountall (Ubuntu):
importance: Undecided → Low
status: New → Triaged

After reviewing mount code, the reason it still passes -f (fake) arguments to mount helpers is so they can choose what they put in mtab.

Thus not supporting -f is a mount.aufs bug

I'm working around this by not calling mount.aufs - no custom mtab entries for you!

Changed in mountall (Ubuntu):
milestone: none → ubuntu-9.10
assignee: nobody → Scott James Remnant (scott)
Changed in mountall (Ubuntu Karmic):
status: Triaged → Fix Committed

This bugs is still present in mountall 0.2.2 package.

I hope attached file could help

A funny behavior happens when i try to "merge" folders in different media.

if my /etc/fstab looks like this:

/dev/mmcblk0p1 /mnt/sd ext4 defaults,noatime 0 1
none /home aufs br=/mnt/sd=rw:/mnt/home=rw,create=mfs:30 0 1

where /dev/mmcblk0p1 is my external sd card.

then the "merged" /home directory DOES NOT CONTAIN any file resident in my sd card.

Instead if my /etc/fstab looks like this:

none /home aufs br=/mnt/test=rw:/mnt/home=rw,create=mfs:30 0 1

where /mnt/test is a folder resident in my internal hard disk

then the "merged" /home directory correctly contain all the files resident in /mnt/test (this also if mountall.log still complain about bad argument passed to mount.aufs).

On Thu, 2009-10-15 at 10:46 +0000, Skumpic wrote:

> This bugs is still present in mountall 0.2.2 package.
Yes... I have COMMITTED the fix, not RELEASED the fix.

Scott James Remnant
<email address hidden>

Changed in mountall (Ubuntu Karmic):
status: Fix Committed → Fix Released
status: Fix Released → Fix Committed

I've uploaded a new version of mountall (0.2.5) to the ubuntu-boot PPA, as usual I would appreciate a little testing before I upload it to the archive proper.


Launchpad Janitor (janitor) wrote :

This bug was fixed in the package mountall - 0.2.5

mountall (0.2.5) karmic; urgency=low

  * Filesystem check progress reporting, including cancellation. LP: 446596.
  * When we're waiting for a mountpoint, if a few seconds of inactivity
    passes, report what we're waiting for and allow Escape to drop you to
    a recovery shell.
  * Start usplash for filesystem check progress reporting or when we've
    been waiting for more than a few seconds. LP: #431184.

  * Hide error removing /forcefsck, people mis-report this as a bug and
    don't tell us the error above it.
  * Don't call mount.ecryptfs or mount.aufs when adding an entry for
    /etc/mtab; these helpers are broken and do not support the -f argument.
    This means your passphrase may end up in /etc/mtab, blame them not me.
    LP: #431954, #443080.
  * Unlink /etc/mtab~ after creating/truncating /etc/mtab and before writing
    mtab entries. LP: #431865.
  * Stop the recovery shell if the user runs shutdown within it, so we
    don't run mountall again. LP: #452196.
  * If the root filesystem check fails, we'll need to reboot, so just have
    the recovery shell script do that.

  * Post-review logic fixes.

 -- Scott James Remnant <email address hidden> Tue, 20 Oct 2009 12:19:16 +0100

Changed in mountall (Ubuntu Karmic):
status: Fix Committed → Fix Released
Rolf Leggewie (r0lf) wrote :

Karmic is past End of Life, and is no longer supported. As such, this bug is being marked "Won't Fix" against the Karmic bug task.

Changed in aufs (Ubuntu Karmic):
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers