Bug 461850 - mkinitd doesn't wait for scsi to come up
mkinitd doesn't wait for scsi to come up
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: mkinitrd (Show other bugs)
5.2
All Linux
high Severity high
: rc
: ---
Assigned To: Peter Jones
Alexander Todorov
:
: 467897 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-10 18:14 EDT by James M. Leddy
Modified: 2014-08-11 01:42 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-20 17:11:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Fix to mkinitrd to wait for scsi (872 bytes, patch)
2008-11-18 11:13 EST, Lubomir Bulej
no flags Details | Diff

  None (edit)
Description James M. Leddy 2008-09-10 18:14:16 EDT
mkinitrd needs to be updated to allow for slower sdX devices

fixed by editing line 1619 of /sbin/mkinitrd


-        emit "stabilized --hash --interval 250 /proc/scsi/scsi"
+        emit "stabilized --hash --interval 1000 /proc/scsi/scsi"


https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&tid=184476


see:
http://www.dslreports.com/forum/r20410231-Centos-51-boot-from-SAN-issue-help-needed-on-resolution

I would have escalated from IT were there not already a bug tracking something else
Comment 1 RHEL Product and Program Management 2008-09-10 18:16:51 EDT
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.
Comment 4 Peter Jones 2008-10-03 12:14:18 EDT
The longer time delay will be in mkinitrd-5.1.19.6-36 .
Comment 6 John Ellson 2008-10-10 15:42:20 EDT
This might be the cause of:
   BZ #466534
   BZ #462233
   BZ #459109


Time delays make me nervous.  Isn't there a way to create an event when SCSI initialization has been completed?
Comment 7 James M. Leddy 2008-10-10 16:46:02 EDT
(In reply to comment #6)
> This might be the cause of:
>    BZ #466534
>    BZ #462233
>    BZ #459109
> 
> 
> Time delays make me nervous.  Isn't there a way to create an event when SCSI
> initialization has been completed?

I understand your concern.  For a broad overview of the way forward in this area, please read http://lwn.net/Articles/298593/ .  Unfortunately, for the short term, nash is the only tool we have.  Here's to the future, when distro's standardize on the process and everything is implemented in the best way possible.
Comment 8 Denise Dumas 2008-10-30 16:28:32 EDT
*** Bug 467897 has been marked as a duplicate of this bug. ***
Comment 9 Alexander Todorov 2008-11-07 04:01:01 EST
I can verify that the line:
emit "stabilized --hash --interval 1000 /proc/scsi/scsi

is present in /sbin/mkinitrd in RHEL5.3 snap #2. However RTT doesn't have the variety of scsi hardware to fully test this issue. Moving to VERIFIED. Please reopen if you still see problems.
Comment 10 Arlinton Bourne 2008-11-07 13:10:16 EST
Bug 464636 also reflects this issue.
Comment 11 Lubomir Bulej 2008-11-18 11:13:04 EST
Created attachment 323916 [details]
Fix to mkinitrd to wait for scsi

Hello,

the attached patch fixes mkinitrd for me, but serves mainly to show the main reason, which is twofold. First, there is a case typo which results in scsi devices not being recognized and the consequently variable wait_for_scsi is not set to "yes". 

The second cause is due to emitmodules() being called twice (once for GRAPHICSMODS modlist, and once for MODULES modlist -- the default). The problem is that when the GRAPHICSMODS modlist is being processed, the wait_for_scsi variable will get unset and will not be used later, when MODULES modlist is being handled. 

The patch fixes the first typo and prevents wait_for_scsi variable to be unset during handling the GRAPHICSMODS modlist.

I consider it rather dirty, but well, so is the emitmodules() function that has side effect on global variables and is suddenly (I assume with advent of plymouth) called twice.
Comment 12 Lubomir Bulej 2008-11-18 11:15:24 EST
Oooops, this should have gone to the Fedora/Rawhide, I'm not sure if this applies to RHEL as well...
Comment 14 errata-xmlrpc 2009-01-20 17:11:55 EST
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-0237.html

Note You need to log in before you can comment on or make changes to this bug.