Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 153099 - Mount by label on startup causes problems when two "/" labels (mount by label needs to be smarter)
Summary: Mount by label on startup causes problems when two "/" labels (mount by labe...
Alias: None
Product: Fedora
Classification: Fedora
Component: util-linux
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2005-04-01 15:35 UTC by Brian "netdragon" Bober
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-03-12 17:08:30 UTC

Attachments (Terms of Use)

Description Brian "netdragon" Bober 2005-04-01 15:35:57 UTC
Description of problem:
I moved the disk from one Fedora system (system B) to another in order (system
A) to back up the entire / contents of that disk to the other system before a
reformat of system B. 

The problem is that initrd attempts to mount all the /var, /tmp, etc, from the
disk moved from system B to hdg of system A, even though they are already
mounted from hda of system A. This, for some reason, causes the /tmp directory
to be read-only and X-Windows to not start up. I know there are ways to change
the mountpoints, but shouldn't the initscripts be a little smarter? 
Actual results:

Moving disk containing "/" from one computer to hdb or hdc or hde, etc will
cause the mountpoints "/var", "/tmp" to attempt to mount again, even though they
are already mounted on hda

/tmp is listed as read-only, and X won't start properly, and /root is also
listed as read-only. I can still ssh in to do the file copies, luckily.

df also shows incorrect results. It leaves out partitions such as /data which is

Expected results:

Since we booted off the hda disk, then any mountpoints such as /var, /tmp, etc
that are already mounted won't be attempted to mount again. I don't know if this
will alleviate the issues, but it's a start.

Is there ever a possibility that a mountpoint could be missing on hda, but have
been on the other system that will cause settings to be changed on boot?

For example, let's say that system A doesn't have a /foo mountpoint, whereas
system B does. If you put system B's drive in system A, then /foo is mounted,
whereas it was never mounted before, and /foo has settings that cause changes to
some settings, but /foo isn't required. Is that possible?

Comment 1 Brian "netdragon" Bober 2005-04-01 16:14:27 UTC
I figured out it's that mount-by-label seems to not handle duplicate labels
properly, and that hda2 and hdg2 both contain the label "/".

I modified /etc/fstab to remove all mount-by-labels, such as:
with their corresponding partitions. The problem went away at that point.

It's not good that this issue exists because of how common it is for people to
mount their old drives on the new system to copy files.

Is there a way that mount-by-label can be a bit smarter and prefer labels on the
disk that was initially booted from?

A side note: during bootup, before changing fstab, when it attempts to mount
/dev/hde2 -> /mnt/ata1, etc that are listed in my fstab, mount returns an error
that device is busy (or something like that). I don't have that issue when
booting without hdg installed.

Comment 2 Karel Zak 2005-04-20 09:35:30 UTC
The mount from util-linux >= 2.12p-7 from FC4 uses cache (/etc/ for
devices and mount prefers cached devices or devices in order hda, hdb, ... (by
/proc/partitions). I think it should be resolve your problem.

Comment 3 Karel Zak 2005-09-08 10:44:07 UTC
Since there are insufficient details provided in this report for us to
investigate the issue further, and we have not received the feedback we
requested, we will assume the problem was not reproduceable or has been fixed in
a later update for this product.

Comment 4 Brian "netdragon" Bober 2005-09-08 16:02:23 UTC
I don't understand comment #2, and what feedback you're requesting. You can
easily reproduce this by having two partitions with the same label, but
different mount points. Have you tried doing that with FC4? I haven't yet
attempted to reproduce this with FC4, but you can easily attempt it by following
the instructions in the bug description. Please let me know if you are unable to

Comment 5 Karel Zak 2005-09-09 09:26:13 UTC
The mount by label handle duplicate labels in FC4. There are two possibility how
the mount command selects right device -- by cache or by device order.


Two same labels:

 # e2label /dev/hda7 TEST
 # e2label /dev/hda8 TEST

1) mount without cache:

  Delete the cache:

    # rm -f /etc/

  Mount by label:

    # mount -L TEST /mnt
    # mount | grep mnt
    /dev/hda7 on /mnt type ext3 (rw)

  Note: the mount used first detected device with the label.

2) mount with cached information about device

  Delete the device cache:

    # rm -f /etc/

  Add information about /dev/hda8 to cache:

    # mount /dev/hda8 /mnt
    # umount /mnt
    note: you can use command 'blkid /dev/hda8' too.
  Mount by label:

   # mount -L TEST /mnt
   # mount | grep mnt
   /dev/hda8 on /mnt type ext3 (rw)

Comment 6 Karel Zak 2005-09-30 15:06:54 UTC
Brian, is the explanation and examples above enough? The problem is not possible
reproduce in FC4.

Note You need to log in before you can comment on or make changes to this bug.