Bug 153099 - Mount by label on startup causes problems when two "/" labels (mount by label needs to be smarter)
Mount by label on startup causes problems when two "/" labels (mount by labe...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: util-linux (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-01 10:35 EST by Brian "netdragon" Bober
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-12 12:08:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Brian "netdragon" Bober 2005-04-01 10:35:57 EST
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
hde2

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 11:14:27 EST
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:
LABEL=/
and 
LABEL=/var
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 05:35:30 EDT
The mount from util-linux >= 2.12p-7 from FC4 uses cache (/etc/blkid.tab) 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 06:44:07 EDT
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 12:02:23 EDT
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
reproduce.
Comment 5 Karel Zak 2005-09-09 05:26:13 EDT
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.

Example:

Two same labels:

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

1) mount without cache:

  Delete the cache:

    # rm -f /etc/blkid.tab

  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/blkid.tab

  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 11:06:54 EDT
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.