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

Reply via email to