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 76467 - At boot time, fsck chokes on LVs listed by label in fstab
Summary: At boot time, fsck chokes on LVs listed by label in fstab
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: util-linux
Version: 4.0
Hardware: i386
OS: Linux
Target Milestone: ---
: ---
Assignee: Karel Zak
QA Contact: Ben Levenson
: 159497 (view as bug list)
Depends On:
Blocks: 156322
TreeView+ depends on / blocked
Reported: 2002-10-22 04:52 UTC by Joshua Jensen
Modified: 2007-11-30 22:07 UTC (History)
4 users (show)

Fixed In Version: RHBA-2005-669
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-10-05 16:48:45 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:669 qe-ready SHIPPED_LIVE util-linux bug fix update 2005-10-05 04:00:00 UTC

Description Joshua Jensen 2002-10-22 04:52:43 UTC
Description of Problem:

At boot time, fsck chokes on LVs listed by label in fstab

Version-Release number of selected component (if applicable):

8.0 stock

How Reproducible:

Simply install RHL 8.0 with some non-root Logical Volumes.
Edit fstab to reference ext2/3 labels in the first column (instead of /dev/VG/LVs)


Actual Results:

on reboot, rc.sysinit fails when fsck says "can't find filesystem"

Expected Results:

mount can find LVs by labels... fsck should be able to also!

Comment 1 Joshua Jensen 2003-01-04 00:05:24 UTC
I believe that this is a problem with Psyche beta3 also.

Comment 2 Joshua Jensen 2004-01-13 14:47:56 UTC
This is a problem with ALL Red Hat releases that use LVM

Comment 3 Thomas Woerner 2004-04-08 13:48:22 UTC
Please have a look at e2fsprogrs-1.35-7 (Fedora Core 2 test). This
should solve this problem.

Comment 4 Joshua Jensen 2004-05-11 12:12:48 UTC
I'll get around to testint Core 2 soon and let you know.

Comment 5 Thomas Woerner 2004-08-16 16:11:56 UTC
Closed due to user inactivity.

Comment 6 Joshua Jensen 2004-08-16 23:45:01 UTC
I'm still here... I just tested with e2fsprogs-1.35-7, now part of FC2
(non-testing), and it still doesn't work.  In fact, the problem seems
to have changed.  Before, the machine's startup would prompt for a
root password as mounting the PV by label would fail.  Now it will
fail if the label doesn't exist, but if it does it will continue
booting, but still print a message "Can not find special filesystem"
or something like that.

Post boot behavior is now different too:

[root@barton root]# e2label /dev/VolumeGroup00/data /data
[root@barton root]# e2label /dev/VolumeGroup00/data 
[root@barton root]# mount /data
mount: no such partition found

This is strange, and different than the original behavior in RHL 8.0

Comment 7 Thomas Woerner 2004-10-06 15:44:34 UTC
Please attach your fstab.

Comment 8 Joshua Jensen 2004-10-07 04:03:29 UTC
The important parts:

LABEL=/                 /                       ext3    defaults     
  1 1
LABEL=/boot             /boot                   ext3    defaults     
  1 2
/dev/VolumeGroup00/data /data                   ext3    defaults     
  1 2
/dev/VolumeGroup00/home /home                   ext3    defaults     
  1 2
/dev/VolumeGroup00/opt  /opt                    ext3    defaults     
  1 2
/dev/VolumeGroup00/usr  /usr                    ext3    defaults     
  1 2

Comment 9 Thomas Woerner 2004-10-07 14:03:14 UTC
Assigning to util-linux, which contains /bin/mount.

Comment 10 Joshua Jensen 2004-11-22 23:01:43 UTC
This seems to be fixed in FC3!!

Comment 11 Joshua Jensen 2004-11-23 20:13:59 UTC
I'll test it again this evening to be sure.

Comment 12 Akkana 2004-11-24 18:14:03 UTC
I saw a similar problem, but it's not related to LVM (please advise if
I should file a new bug).  I installed FC3 on a machine which already
had two OSes installed on other partitions: a Redhat 7.3 (ext2) and a
SuSE 9.1 (reiserfs).  On the first reboot after installing, I was
dumped into a single-user shell with a message that fsck.ext3 was
finding errors on hda2 (the suse partition, reiserfs!)  This partition
were not mentioned in fstab and I had not done anything with them in
disk druid during the install; there is no reason it should have been
fsck'ed during boot, and certainly not by fsck.ext3.

The problem may have something to do with the LABEL=/: the existing
RH7.3 already used LABEL=/ for its partition, so the FC3 installer
labelled its new partition /1 but then put LABEL=/ into fstab. 
(Though the problem was with the SuSE reiser partition, not with the
old RH73 ext2 partition.)  A "mount -o rw,remount /" followed by
editing fstab to replace the LABEL=/ and LABEL=/boot with the actual
partition names (/dev/hda2 and /dev/hda1) and another reboot fixed the

Comment 13 Joshua Jensen 2004-11-24 22:49:26 UTC
Hmmm... in FC3 I see this when manually mounting /dev/VolGrp00/opt
(which has the label of /opt):

[joshua@mule var]$ sudo mount -L /opt
mount: the label /opt occurs on both /dev/dm-3 and
/dev/mapper/VolGrp00-opt - not mounted

Is udev getting in our way here?

Comment 14 Joshua Jensen 2004-11-29 15:35:58 UTC
Worth noting that the original problem, that fsck didn't look for
LABEL'ed filesystems on LVM is no longer a problem.   Should I open a
new bugzilla for the /dev/dm-3 and /dev/mapper/VolGrp00-xyz
"duplication" ??

Comment 15 Elliot Lee 2004-12-02 20:23:22 UTC
What is /dev/dm-3?

It's known that mount refuses to mount something when there are
duplicate labels (solution: don't do that).

Comment 16 Joshua Jensen 2004-12-02 20:50:26 UTC
/dev/dm-3 is a udev creation.... though I've not touched anything
udev, it seems to by default create some /dev/dm-# devices based on
what LV/partitions/filesystems (??) it sees

Comment 17 Elliot Lee 2004-12-10 16:50:24 UTC
udev may get in the way here *when run with a 2.4 kernel*.

If you are running a 2.6 kernel and get the 'duplicate labels' error
message when trying to mount an LVM LV, please post the contents of

Comment 18 Joshua Jensen 2004-12-11 03:34:12 UTC
I'm running FC3 with all updates.

[joshua@mule ~]$ more /proc/partitions
major minor  #blocks  name

   3     0  199147487 hda
   3     1     987966 hda1
   3     2          1 hda2
   3     5    9775521 hda5
   3     6    9775521 hda6
   3     7    9775521 hda7
   3     8  168827053 hda8
   3    64   78150744 hdb
   3    65    9765976 hdb1
   3    66   68384736 hdb2
  22     0   78150744 hdc
  22     1   39070048 hdc1
  22     2   32611950 hdc2
  22     3    6466162 hdc3
 253     0    6291456 dm-0
 253     1   93323264 dm-1
 253     2   33554432 dm-2

Comment 19 Joe Orton 2004-12-14 19:32:07 UTC
Same issue here: in FC3 it looks like udevstart is creating the
/dev/dm-* devices, but I can't see when they would be used, so maybe
it shouldn't.  Harald?


Comment 20 Elliot Lee 2004-12-14 19:39:10 UTC
The /dev/dm-X devices are listed in /proc/partitions, so they do
become useful at times.

I know what the bug is here - it's just a matter of getting around to
fixing it.

Comment 21 Akkana 2004-12-14 22:04:01 UTC
Should I split off the non-LV version of this (comment 12) into a
separate bug?  Or does the bug you're going to fix cover non LVs too?

Comment 22 Elliot Lee 2004-12-15 00:03:01 UTC
The situation described in comment #12 is supposed to happen
(NOTABUG). When a label is ambiguous, it is better to error out than
risk possible data corruption.

Comment 23 Joshua Jensen 2004-12-15 00:34:07 UTC
I agree with Elliot, nether udev nor mount are to blame.  However,
their behavior when working *together* isn't what was indented: mount
by label *should* work, and it doesn't.

Does mount need to have a /dev/dm-# ignore check, or could udev do
something differently to not present the same partition twice?

Comment 24 Akkana 2004-12-15 00:47:53 UTC
Shouldn't it error out in the installer, rather than proceeding with
the install, writing a label to fstab that's different from the label
it actually used for the filesystem, rebooting, then trying to fsck an
unrelated filesystem using the wrong fsck program, possibly causing
data loss on one of the existing partitions?  

Comment 25 Joshua Jensen 2004-12-15 01:04:13 UTC
Is udev running in the installer?  The problem isn't there to my
knowledge, rather it is after reboot when mount/fsck are trying to
find things by label, and udev has made duplicate /dev/ device files.

Comment 26 Harald Hoyer 2004-12-15 01:28:50 UTC
are you sure udev created both devnodes? I think udev only created one
and the other is created in rc.sysinit by:
    /sbin/lvm.static vgscan --mknodes 
and maybe
    echo "mkdmnod" | /sbin/nash --quiet >/dev/null 2>&1

Comment 27 Harald Hoyer 2004-12-15 01:31:35 UTC
if wanted, I can disable LVM devnode creation by udev, but I think we
better fix the tools to check for major:minor numbers.

Comment 29 Elliot Lee 2005-01-03 22:51:50 UTC
The patch in EL4.5 was rejected & reverted for RHEL4, but it should be
in the devel tree just fine.

Comment 30 Joshua Jensen 2005-05-06 18:12:30 UTC
So this fix won't make it into RHEL4 ?  Since RHEL4 is very very close to FC3,
we  have this problem there to, right?

Comment 31 Joshua Jensen 2005-05-06 18:15:57 UTC
Reopening as this is still a problem in RHEL4

Comment 32 Karel Zak 2005-05-12 07:19:26 UTC
* Fri May  6 2005 Karel Zak <> 2.12a-24.2
- fix #156949, #76467 - mount reads information about dm- LABELs two times

I don't see any problem fix it in RHEL4-U2. The patch doesn't seem too invasive.

Comment 34 Jay Turner 2005-05-18 02:26:21 UTC
QE ack . . . already included in FC so has received testing.

Comment 35 Joshua Jensen 2005-05-24 19:09:02 UTC
Excellent!  So do you think this will make U2 of RHEL4 ?

Comment 36 Karel Zak 2005-06-03 00:07:01 UTC
*** Bug 159497 has been marked as a duplicate of this bug. ***

Comment 40 Red Hat Bugzilla 2005-10-05 16:48:45 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

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