Red Hat Bugzilla – Bug 76467
At boot time, fsck chokes on LVs listed by label in fstab
Last modified: 2007-11-30 17:07:11 EST
Description of Problem:
At boot time, fsck chokes on LVs listed by label in fstab
Version-Release number of selected component (if applicable):
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)
on reboot, rc.sysinit fails when fsck says "can't find filesystem"
mount can find LVs by labels... fsck should be able to also!
I believe that this is a problem with Psyche beta3 also.
This is a problem with ALL Red Hat releases that use LVM
Please have a look at e2fsprogrs-1.35-7 (Fedora Core 2 test). This
should solve this problem.
I'll get around to testint Core 2 soon and let you know.
Closed due to user inactivity.
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
Please attach your fstab.
The important parts:
LABEL=/ / ext3 defaults
LABEL=/boot /boot ext3 defaults
/dev/VolumeGroup00/data /data ext3 defaults
/dev/VolumeGroup00/home /home ext3 defaults
/dev/VolumeGroup00/opt /opt ext3 defaults
/dev/VolumeGroup00/usr /usr ext3 defaults
Assigning to util-linux, which contains /bin/mount.
This seems to be fixed in FC3!!
I'll test it again this evening to be sure.
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
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?
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
What is /dev/dm-3?
It's known that mount refuses to mount something when there are
duplicate labels (solution: don't do that).
/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
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
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
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?
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
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?
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.
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?
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?
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.
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
echo "mkdmnod" | /sbin/nash --quiet >/dev/null 2>&1
if wanted, I can disable LVM devnode creation by udev, but I think we
better fix the tools to check for major:minor numbers.
The patch in EL4.5 was rejected & reverted for RHEL4, but it should be
in the devel tree just fine.
So this fix won't make it into RHEL4 ? Since RHEL4 is very very close to FC3,
we have this problem there to, right?
Reopening as this is still a problem in RHEL4
* Fri May 6 2005 Karel Zak <email@example.com> 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.
QE ack . . . already included in FC so has received testing.
Excellent! So do you think this will make U2 of RHEL4 ?
*** Bug 159497 has been marked as a duplicate of this bug. ***
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.