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. 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. kind regards -- maks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
