Virtual (aufs) root device never ready

Bug #431204 reported by Stéphane Graber on 2009-09-17
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
mountall (Ubuntu)
High
Scott James Remnant (Canonical)
Karmic
High
Scott James Remnant (Canonical)

Bug Description

Binary package hint: mountall

Setup: mountall 0.1.6 on LTSP (but may apply to similar setups) whith an empty /etc/fstab (from debootstrap) and a /etc/mtab that's a link to /proc/mounts.

When booting, the boot process hangs waiting for a last mountpoint to appear.

Modifying the init script and having it drop to a shell, then starting ssh from it and connecting from another computer, I'm able to manually mount /dev/pts so I can get a working console, then mount a tmpfs on top of /tmp and run mountall again.
Doing so will make the boot process to continue.

The way the root filesystem is mounted is similar to the LiveCD except that we don't mount a tmpfs on top of /tmp as modifications to the whole system are already stored in a tmpfs through aufs.
So, basically:
 / => aufs
 /cow => tmpfs
 /rofs => squashfs mounted from /dev/nbd0 (nbd drive)

As a workaround, I modified the init script so it does the same as described above. Adding /tmp as tmpfs to /etc/fstab should also fix the issue although it's not something we should need as / is read-write and perfectly usable as root.

From the shell, could you run mountall --debug and capture the output - attaching it to this bug

Changed in mountall (Ubuntu):
importance: Undecided → High
status: New → Incomplete
summary: - mountall stuck when waiting for mount points on LTSP setups
+ stuck waiting for mount points on LTSP setups

This is stuck because the root filesystem is a virtual filesystem, but mountall is hardcoded to believe it's a local filesystem, so the device is never considered "ready"

Changed in mountall (Ubuntu):
status: Incomplete → Triaged
summary: - stuck waiting for mount points on LTSP setups
+ Virtual (aufs) root device never ready
Changed in mountall (Ubuntu Karmic):
assignee: nobody → Scott James Remnant (scott)
tags: added: ubuntu-boot
Changed in mountall (Ubuntu Karmic):
milestone: none → ubuntu-9.10-beta
Test-tools (roland-verifysoft) wrote :

Hello ,

bug #433768 has probably an explanation...

Roland "Test-tools" Bär

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

The ubuntu-boot PPA has a new version of mountall which I hope will fix this problem, please install that and let me know how it works out.

Stéphane Graber (stgraber) wrote :

Did a quick test with your PPA (had to dpkg -i the package as another upload as been done in the archive in the mean time).
Seems to work well, both when started manually and when using the regular init script.

Thanks

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package mountall - 0.1.8

---------------
mountall (0.1.8) karmic; urgency=low

  [ Scott James Remnant ]
  * Further work on the fix from the previous version where the root
    filesystem would always be considered "local", retain that from the
    POV of the {virtual,local,remote}-filesystems events, but do mount
    the root straight away when it's virtual since there's no device to
    wait until it's ready. LP: #431204.
  * If a remote filesystem is already mounted and doesn't need a remount,
    don't wait for a network device to come up. LP: #430348.

  * Ignore single and double quotes in fstab device specifications, since
    mount -a used to. LP: #431064.
  * Never write mtab when mounting a mount with showthroughs (ie. /var)
    and instead update mtab once we've moved it into place
    later. LP: #434172.

  [ Kees Cook ]
  * src/mountall.c: rework nftw hooks to use a global for argument passing
    instead of using nested functions and the resulting trampolines that
    cause an executable stack. LP: #434813.
  * debian/rules: revert powerpc exception, since the cause is fixed by
    removing the nested functions.

 -- Scott James Remnant <email address hidden> Wed, 23 Sep 2009 14:19:01 -0700

Changed in mountall (Ubuntu Karmic):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers