Bug 1351430
| Summary: | System fails to boot and drops into emergency shell after failing to mount /boot on multipath device | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | shivamerla1 <shiva.krishna> |
| Component: | device-mapper-multipath | Assignee: | Ben Marzinski <bmarzins> |
| Status: | CLOSED ERRATA | QA Contact: | Zhang Yi <yizhan> |
| Severity: | high | Docs Contact: | Steven J. Levine <slevine> |
| Priority: | unspecified | ||
| Version: | 7.2 | CC: | agk, bmarzins, heinzm, jbrassow, lilin, mnavrati, msnitzer, prajnoha, raunak.kumar, shiva.krishna, yizhan, zchuang |
| Target Milestone: | rc | Keywords: | OtherQA |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | device-mapper-multipath-0.4.9-95.el7 | Doc Type: | Bug Fix |
| Doc Text: |
~~~Included in the Release Notes as a description for BZ#1350931~~~
Cause: When multipathd created a new multipath device, it didn't allow any more paths to be added until it saw the udev change event for the multipath device being created, even if it created the device with no usable paths.
Consequence: If a multipath device was created with no usable paths, udev hangs trying to get information on the device, and bootup can timeout
Fix: Multipathd now allows paths to be added to a newly created multipath device, if it currently has no usable paths.
Result: usable paths are immediately added to new devices that have none, and udev doen't hang.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-11-04 08:20:11 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
shivamerla1
2016-06-30 04:57:31 UTC
Patch which seems to have caused this. https://www.redhat.com/archives/dm-devel/2016-March/msg00146.html I'm fairly certain that the delay can safely be removed in the initramfs. Are you able to boot the machine up at all? If so, I can give you a test package that will disable this behavior during the initramfs. Yes, we are able to boot into rescue kernel. Please provide the test package we can verify that. hello shivamerla1, There is no Nimble storage in our lab, so could you feedback test result once the fixed version is available? thanks Sure, we can test the private packages and provide feedback. Could you please try the packages available at http://people.redhat.com/~bmarzins/device-mapper-multipath/rpms/RHEL7/bz1350931/ and see if this resolves your issue. You will need to remake the initramfs after installing these packages. These packages should also fix Bug 1350931 Thanks Ben, These packages seems to fix the issue we have encountered. System boots fine without issues. Please let us know when will updates be available with the fix. Do you know if this also fixes Bug 1350931? Yes Ben, I did basic sanity test and it does fix the Bug 1350931. Thanks Hello shivamerla1 Would you pls help test this bug and BZ1291406 with the fixed package? Thanks in advance. Yi We have already verified the fix with private package. It looks good from our side. (In reply to shivamerla1 from comment #14) > We have already verified the fix with private package. It looks good from > our side. Hi shivamerla1 Thanks for your confirmation, change to VERIFIED. Yi Is it possible to provide this fix as part of 7.2 Errata release for device-mapper-multipath?. Currently its only available through Beta repos, which our customers might not be willing to upgrade. Ben: The doc text for the release note description is nearly identical to the doc text that was provided for the release note description in BZ#1350931. Is this the same fix? It seems as though we only need to describe this once in the release notes (while referencing both bugs). Steven (In reply to Steven J. Levine from comment #17) > Ben: > > The doc text for the release note description is nearly identical to the doc > text that was provided for the release note description in BZ#1350931. Is > this the same fix? It seems as though we only need to describe this once in > the release notes (while referencing both bugs). > > Steven Yep. These are the same issue. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2536.html |