I'm sorry, but I am unable to replicate this bug; in order to help debug
it, you will need to provide more information.

The test setup I used had two 8GB SCSI drives, partitioned as follows:
  /dev/sd[ab]1 -> md0 -> /boot
  /dev/sd[ab]2 -> swap
  /dev/sd[ab]5 -> md1 -> LVM PV

LVM is configured with a single VG (UbuntuVG) with two LVs (root and
var)

/dev/mapper/UbuntuVG-root (actually its UUID) is mounted on /
/dev/mapper/UbuntuVG-var (actually, its UUID) is mounted on /var

The system responds as I would expect.

/var/run and /var/lock are mounted early on the stub mountpoints that
the installer creates on the root filesystem for this purpose (so the
root has /var, /var/run and /var/lock directories).

Then during mountall, these are bind-mounted in /dev/shm so that other
filesystems can be mounted over the top; once mount -a has completed
(ie. the new /var is in place), the filesystems from /dev/shm are move-
mounted back into /var/run and /var/lock which may now be on a different
filesystem.

The problem *may* be simply caused by a missing /var/run and /var/lock
on the root filesystem, which will prevent these mountpoints existing at
all!  Could you describe the symptoms that this problem causes you?

If you're running gutsy, ensure you are up to date.  The latest
initscripts package (2.86.ds1-14.1ubuntu30) contains a fix that makes
sure that these mount targets exist on the root filesystem (by creating
them on shutdown before it's mounted read-only, but after other
filesystems are mounted).

** Changed in: sysvinit (Ubuntu)
Sourcepackagename: upstart => sysvinit
       Status: Confirmed => Incomplete
       Target: ubuntu-7.10-rc => None

-- 
/var is mounted too late during the init sequence
https://bugs.launchpad.net/bugs/139230
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to