Bug 570460
| Summary: | Installation to multipath node fails | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Alex Zeffertt <alex.zeffertt> | ||||
| Component: | mkinitrd | Assignee: | Brian Lane <bcl> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Release Test Team <release-test-team-automation> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 5.4 | CC: | dafydd, ddumas | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-10-21 23:35:45 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
This may be our problem. This is seen in the wild on boot with "device-mapper: table: 253:0: multipath: unknown hardware handler type" I can install from DVD (RHEL 5.4, to which I am limited) or kickstart without error. On reboot following install, the "253" error is typically found in the console. I'm booting a diskless IBM HS22V connected to an IBM DS5020 SAN LUN for its disk. For multipathd, the vendor "IBM", product "1814" entries already exist. This is a Sev 1, Pri 1, for us. It's blocking the installation of a medium-sized blade farm. More information, with console output, command output, and configurations, are available in Support Case 00442947. I just verified installing/running mkinitrd-5.1.19.6-54. Try out the patch and see if that fixes it. If it does, maybe Red Hat will take it. /sbin/mkinitrd -v \ --with=dm-mod \ --with=dm-multipath \ --with=dm-round-robin \ --with=scsi_dh_rdac \ <outfile>.gz `uname -r` will function as a workaround. Hi, Alex, I didn't see your comment until I posted my workaround. Is the patch in .rpm format? I don't get a file extension when I try to download it. (Yes, I'd love for this to be taken. Particularly as errata!) (In reply to comment #3) > Try out the patch and see if that fixes it. If it does, maybe Red Hat will > take it. Hi, Alex, Okay, I just opened up the diff. The bad news is that my managers aren't going to want me to take the time to get the mkinitrd source, apply the diff, and recompile. Even if I got that far, I wouldn't be allowed to put the result in any package repository where it might get out. The only way I'm going to get a package into our blade environment is if RH gives me an RPM to test. And, the only way I could talk my bosses into that would be if they were comfortable that a follow-on official update/Errata would be available once the fix was confirmed. (In reply to comment #3) > Try out the patch and see if that fixes it. If it does, maybe Red Hat will > take it. dafydd wrote: > I didn't see your comment until I posted my workaround. Is the patch in .rpm > format? I don't get a file extension when I try to download it. Yes, you can use the patch as part of the rpm. The file extension doesn't matter. Note, you will need to add a couple of lines to the spec file as well in order to make the patch get applied. Brian wrote: > Alex, does comment 4 fix it for you? Unfortunately it was over a year ago I was working on this and so I am not able to test this without setting up a load of equipment. However, what worked for us was rebuilding the RPM with the patch. I expect that dafydd's mkinitrd command line would work fine for some of the hardware I have used this on, but not all. This is because it only causes the scsi_dh_rdac module to be included in the initrd, whereas the patch causes the scsi_dh_emc module to be included as well. Regards, |
Created attachment 397789 [details] make initrd always insmod scsi_dh_emc and scsi_dh_rdac if root multipathed Description of problem: Installation to multipath node fails for disks with non-default hardware_handlers in /etc/multipath.conf. This is because mkinitrd fails to insmod the required handler (either scsi_dh_emc.ko or scsi_dh_rdac.ko). When the initrd runs "/sbin/multipath -v 0 $wwid" the kernel fails to create the map and generates the following warning: device-mapper: table: 251:0: multipath: unknown hardware handler type device-mapper: ioctl: error adding target to table Version-Release number of selected component (if applicable): mkinitrd-5.1.19.6-54 How reproducible: 100% Steps to Reproduce: 1. Create multipath node on DGC device 2. install a rhel root filesystem on partition of node 3. specify /dev/mapper/ node in fstab 3. chroot to root filesystem and run mkinitrd Actual results: Creates an initrd which does not insmod scsi_dh_emc.ko. This means that initrd will fail when it runs /sbin/multipath to create the dev mapper node. Expected results: initrd should insmod scsi_dh_emc.ko Additional info: See patch