Don't place LABEL= in /etc/fstab by default, even if the filesystem has one

Bug #347817 reported by Scott James Remnant (Canonical) on 2009-03-24
Affects Status Importance Assigned to Milestone
Release Notes for Ubuntu
Colin Watson
installation-guide (Ubuntu)
Colin Watson
partman-target (Ubuntu)
Colin Watson

Bug Description

Binary package hint: partman-target

When we originally discussed the "probe for root filesystem" spec, which let to mounting by UUID, the possibility of mounting by LABEL instead was considered.

We explicitly rejected it because LABELs are likely to be descriptive about the purpose of the filesystem, for example being "/", "root", "/home", "home", etc. This means that adding another disk to the system can cause a clash to existing labels.

Because there is no clear winner for a LABEL, which disk is used is effectively random. (USB disks tend to win over SATA disks, but not always).

A typical failure scenario would be plugging in a USB disk which was previously the "home" disk of another computer; that disk could steal the "home" label from the /home filesystem of the computer it was plugged into. Even if you intend to format it and change the label, the period before that could lead to the wrong disk being mounted as /home.

Thus we decided to support users wanting to use LABEL, but only write UUID by default.

Please change the installer to only write UUIDs by default; of course, it's perfectly acceptable to write LABEL if the user says they want to, for example with a preseed, or with a checkbox in the same place you enter the LABEL, etc.

Since the installer has been writing LABEL to /etc/fstab by default, we should deal with upgrades somehow. I think that the best approach is simply a release note along the lines of:

 "systems installed for alpha N or beta may use LABEL in /etc/fstab - and that this could cause
  unexpected behaviour if another disk with the same label is added later.

  to find the UUID use:

        blkid -o value -s UUID -l -t LABEL=xxxx

  then put this as UUID=yyyy in /etc/fstab"

Steve Langasek (vorlon) wrote :

What needs to be documented in the release notes? This issue is going to be resolved for release, right?

Changed in ubuntu-release-notes:
status: New → Incomplete
Colin Watson (cjwatson) wrote :

It'll be resolved for release (I just committed a fix), but I think we should document the issue for upgraders from beta. I agreed with Scott that it wasn't critical to respin beta for this.

Changed in partman-target (Ubuntu):
assignee: nobody → cjwatson
importance: Undecided → High
status: New → Fix Committed
Colin Watson (cjwatson) on 2009-03-26
Changed in ubuntu-release-notes:
importance: Undecided → Medium
status: Incomplete → Triaged
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package partman-target - 58ubuntu6

partman-target (58ubuntu6) jaunty; urgency=low

  * Rather than pretending that partitions have no longer been formatted
    after the partitioner is complete, reset their intended state from
    "format the partition" to "keep and use the existing data". This still
    solves the original problem reported in Debian bug #256090 while also
    stopping partitions from being needlessly reformatted if you go back to
    the partitioner after base system installation and then forward again
    (LP: #29712).
  * Don't clear partitions or complain about them not being formatted if
    they've already been formatted by a previous partitioner run.
  * Introduce partman/mount_style (choices: traditional, label, uuid) to
    allow controlling how filesystems are mounted. Default this to uuid, and
    stop using labels by default since they have unavoidable problems with
    removable disks (LP: #347817).

 -- Colin Watson <email address hidden> Fri, 27 Mar 2009 11:59:04 +0000

Changed in partman-target:
status: Fix Committed → Fix Released
Colin Watson (cjwatson) on 2009-03-27
Changed in installation-guide (Ubuntu):
assignee: nobody → cjwatson
importance: Undecided → Medium
status: New → Triaged
Colin Watson (cjwatson) wrote :

Release notes text added:

== Upgrades from beta use LABEL in /etc/fstab ==

Systems installed using Jaunty Alpha 5, Jaunty Alpha 6, or the Ubuntu 9.04 beta may use `LABEL=` syntax in `/etc/fstab` to identify file systems. This may cause unexpected behaviour later if another disk (such as a USB drive) is added later containing file systems with clashing labels. Unless you are sure that this is what you intend, we recommend that you switch to using universally unique identifiers (UUIDs) instead.

For example, if a file system is identified as `LABEL=home` in `/etc/fstab`, you can find the UUID as follows: {{{
blkid -o value -s UUID -l -t LABEL=home
}}} You can then replace `LABEL=home` with `UUID=output`, where `output` is the output of blkid.

Systems installed using the release candidate or final release of Ubuntu 9.04 do not have this problem.

Changed in ubuntu-release-notes:
assignee: nobody → Colin Watson (cjwatson)
status: Triaged → Fix Released
Colin Watson (cjwatson) on 2009-04-16
Changed in installation-guide (Ubuntu):
status: Triaged → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package installation-guide - 20081208ubuntu3

installation-guide (20081208ubuntu3) jaunty; urgency=low

  * Document pkgsel/updatedb (LP: #8195).
  * Document partman/default_filesystem.
  * Document controlling how partitions are mounted (LP: #347817).
  * Mention that Kickstart LVM configuration is now experimentally
    supported, and document the pieces currently known to be missing.
  * Update Canonical's copyright years.

 -- Colin Watson <email address hidden> Thu, 16 Apr 2009 21:56:50 +0100

Changed in installation-guide (Ubuntu):
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