Description of problem:
Some of the time, the LVM2 init section of rc.sysinit will be ineffective.
Specifically, vgscan will not find any volume groups. I believe that the system
started up normally once, but since has not done so without modifications to the
I've determined that if I add a 'sleep' to rc.sysinit, immediately before
calling vgscan, vgscan will locate the volume groups. I'm using 30 seconds now,
but don't know what minimum is required.
I'm guessing that the device mapper hadn't found the volume on sdb yet, but I'm
not sure how I'd prove it without more knowledge of the way that those kernel
Version-Release number of selected component (if applicable):
Unsure, but it seems consistent and reproducible here.
Steps to Reproduce:
1. Create LVM device (ours is a 4.55TB volume with just one PV: /dev/sdb)
3. Log in and check "vgdisplay", you'll see no volumes have been found.
vgscan didn't find the volume we'd created, when run during rc.sysinit, unless
there was a brief pause after loading the dm_mod module.
vgscan should find the volume, and vgchange should activate it.
sdb is a RAID5 volume on a 3ware 9550SX card. We used LVM because we plan to
put a second card and set of disks in the system at some point, and will want to
include those disks in the same filesystem.
Hm, can you get a strace of it failing?
Yeah, sure. I traced the process before and after the sleep, and saw that "sdb"
didn't exist in /dev on the first run. Afterward, I also got the output of 'ls
-lR /dev' before and after the 'sleep'.
Created attachment 132391 [details]
ls -lR /dev, during LVM2 init in rc.sysinit
Created attachment 132392 [details]
ls -lR /dev, during LVM2 init in rc.sysinit, after sleeping
Created attachment 132393 [details]
strace of vgscan, during LVM2 init in rc.sysinit
Created attachment 132394 [details]
strace of vgscan, during LVM2 init in rc.sysinit, after sleeping
How hard would it be to add something like udevsettle to RHEL 4's udev?
*** Bug 178728 has been marked as a duplicate of this bug. ***
would be possible, not sooo hard.
is this still a problem?
I may be able to check next week, when summer vacation begins. The only system
where we see this problem is a file server for our students. I don't have a
test system on which to reproduce the problem outside of the production environment.
We updated the system today, and it seems to be fixed. If the problem comes
back, I'll reopen this bug.
I just encountered this bug on a RHEL 4.4 fully updated system. (Which means
RHEL 4.5) I inserted a "sleep 20" around line 512. After the sleep the device
/dev/sdb exists and the vgchange command activates its logical volumes.
sdb is a 10T JetStor 516F connected via 4Gb FC to a QLogic QLE2460 HBA and the
hardware platform is a Dell 2950.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
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 therefore 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.