Red Hat Bugzilla – Bug 461850
mkinitd doesn't wait for scsi to come up
Last modified: 2014-08-11 01:42:30 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"
I would have escalated from IT were there not already a bug tracking something else
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
The longer time delay will be in mkinitrd-18.104.22.168-36 .
This might be the cause of:
Time delays make me nervous. Isn't there a way to create an event when SCSI initialization has been completed?
(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.
*** Bug 467897 has been marked as a duplicate of this bug. ***
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.
Bug 464636 also reflects this issue.
Created attachment 323916 [details]
Fix to mkinitrd to wait for scsi
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.
Oooops, this should have gone to the Fedora/Rawhide, I'm not sure if this applies to RHEL as well...
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.