Doesn't create /var/run or /var/lock directories underneath /var mountpoint

Bug #44142 reported by Scott James Remnant (Canonical)
26
Affects Status Importance Assigned to Milestone
partman-target (Ubuntu)
Fix Released
Critical
Colin Watson

Bug Description

If the user decides to have /var on a separate mountpoint, ubiquity just copies the current system without taking care to make /var/run or /var/lock *underneath* this mountpoint so that they are available during early boot, before /var itself has been mounted.

On the non-ubiquiuty system this is taken care of by the initscripts postinst on either fresh installation, or on upgrade from breezy (so dpkg-reconfigure isn't sufficient on this).

This can be fixed by either deliberately making empty /var/run and /var/lock directories on the root filesystem before mounting the /var partition over top, or by running the initscripts postinst with just "configure" as an argument -- which bind-mounts the root filesystem elsewhere so that the directories can be made on it rather than the /var filesystem.

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Critical because this causes any installation with a separate /var to fail to boot correctly

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :
Simon Law (sfllaw)
Changed in ubiquity:
status: Unconfirmed → Confirmed
Revision history for this message
Colin Watson (cjwatson) wrote :

I think I'd rather do this in partman-target while it's mounting filesystems.

Changed in ubiquity:
assignee: nobody → kamion
Revision history for this message
Colin Watson (cjwatson) wrote :

This should sort it out:

partman-target (41ubuntu1) dapper; urgency=low

  * Create /var/lock and /var/run on the root filesystem before /var is
    mounted, so that udev can use them (closes: Malone #44142).

 -- Colin Watson <email address hidden> Thu, 11 May 2006 10:17:10 +0100

I'll incorporate this into ubiquity as part of my next upload.

Changed in partman-target:
status: Confirmed → Fix Released
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.