mountall passes bad arguments to /sbin/mount.aufs

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

Bug Description

Binary package hint: mountall

Ok,
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 :

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

Test-tools (roland-verifysoft) wrote :

Correction:
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 :

Hello,

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
--
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.

Thanks

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