On Fri, Jul 17, 2009 at 8:45 AM, maximilian attems <m...@stro.at> wrote:
> On Fri, 17 Jul 2009, Robert LeBlanc wrote: > > > Thanks for looking into it. A little more info about the problem that I > have > > so that when implementing a fix, it will be covered. > > > > 1. Most devices settle (Fibre Channel is settled at this point) > > 2. local script is executed which runs all the scripts in local-top (this > is > > where LVM and madam (I think) are run to activate the LVM VG or build the > > madam RAID, but the SCSI disk that my LVM is on has not been found yet, > so > > nothing is activated) > > 3. wait_for_udev 10 (This returns immediately as udev for some reason > thinks > > everything is settleted) > > 4. Init waits for ROOT to show up. > > 5. 3.5 seconds later, the SCSI disk with LVM show up, but LVM VG is never > > tried to be activated again. > > 6. About 177 seconds later init gives up looking for root and drops to a > > shell. > > sure, full ack on the analysis. > current workaround is to boot with appropriate rootdelay=<sec> bootarg. > this is also recommended in the release notes. > I don't think rootdelay does that, from what I can tell in the script, it only defines how long to do the Wait for Root to show up script, which happens after local-top is run. If scsi_wait_scan will work, then that sounds good, it's not working currently though as you stated. > > a more profund way is to modprobe scsi_wait_scan in the udev script. > cc udev Maintiner to getting an update on the status of that? > > > So by moving the execution of the local-top scripts execution, when it is > > waiting for ROOT to show up, it is also looking to see if there are new > > devices that have LVM or madam partitions that can be used as root, > instead > > of only basic partitions. I tried to make the workaround/fix as generic > as > > possible. > > > > Thank you, > > > > Robert LeBlanc > > Life Sciences & Undergraduate Education Computer Support > > Brigham Young University > > well current scripts don't mind to be run X time, but this loop shouldn't > be needed. scsi_wait_scan needs however still to be ported to ata drivers, > but it is already widely implemented in scsi drivers. > The loop was already there, I just reordered some of the script to make use of the loop. Thanks, Robert LeBlanc Life Sciences & Undergraduate Education Computer Support Brigham Young University