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 rc.sysinit file. 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 components function. Version-Release number of selected component (if applicable): initscripts-7.93.24.EL-1.1 How reproducible: 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) 2. Reboot 3. Log in and check "vgdisplay", you'll see no volumes have been found. Actual results: 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. Expected results: vgscan should find the volume, and vgchange should activate it. Additional info: 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 release.
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. http://rhn.redhat.com/errata/RHBA-2009-1004.html