Bug 1173389
| Summary: | GPT partitions not initially found by kernel/systemd after kernel upgrade to 3.18 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jillian Morgan <penguin.wrangler> |
| Component: | device-mapper-multipath | Assignee: | systemd-maint |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 20 | CC: | agk, bmarzins, dwysocha, fdinitto, heinzm, johannbg, jsynacek, lnykryn, lvm-team, msekleta, msnitzer, prajnoha, prockai, s, systemd-maint, vpavlin, zbyszek |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-01-08 19:57:54 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
Jillian Morgan
2014-12-12 03:00:40 UTC
In double-checking the difference between the successful 3.17.3 boot and the failed 3.18 boot, I found that in 3.17.3 that my partitions sda1 and sdb1 were being remapped by multipathd, so my RAID0 was actually being found on devices dm-3[0] dm-2[1]. Blargh!
I always disable or remove multipathd because I've been bitten in the a** more than a few times by it causing problems on many different systems. Somehow it got re-enabled (probably by an overzealous update) and was purely lucky that it still worked until now.
That being said, something about 3.18 is not happy with multipathd (or vice-versa more likely). I don't know if multipathd is failing to remap the partitions or what (nothing in any logs I can find). I have worked around the problem by disabling multipathd, -- again! --:
# systemctl disable multipathd
and just for good measure, in case something causes it to be forcefully started:
# echo >> /etc/multipath.conf << EOF
blacklist {
devnode "*"
}
EOF
On other systems, I always remove device-mapper-multipath and it's ilk entirely, but here I'm running oVirt, and vdsm has an RPM dependency on device-mapper-multipath for whatever reason, so I cannot remove it.
There's a bug here somewhere, probably with multipathd (someone should just take it out behind the shed and **BLAMO**.. put it out of it's misery), but for now the above workaround allows the system to boot successfully.
I'm changing this bug's component to "device-mapper-multipath", because I've got a strong suspicion that's where the root of the problem lies.
Someone feel free to reduce the Severity from urgent to high -- I don't seem to be able to.
First off, are /dev/sda and /dev/sdb actually different paths to the same device? Or do you not have any devices with multiple paths? If you don't,
then adding
defaults {
find_multipaths yes
}
to /etc/multipath.conf, and then running
# rm /etc/multipath/wwids
should fix this. This should be the default set by anaconda, but there was recently a bug that caused it not to get set. It will make multipath ignore devices without multiple paths. You should also note that since your problem is happening in your initramfs, you need to remake that after changing /etc/multipath.conf, so the file can be copied to the new initramfs image.
Thanks for the info, Ben. Good to know that it is a misconfigured-by-default issue. For the record, my sda and sdb are independent devices (two 3TB WD Reds in a RAID0, then a bcache SSD layer on top of that). There are no devices in this system with multiple paths. Also, I do not use any initramfs. Since I have no need for multipathd, either fix effectively resolves my problem by making multipathd go sit quietly in the corner and get out of the way. I would just remove it entirely if not for the RPM dependency from vdsm. :-( Also, if you remove /etc/multipath.conf entirely, then systemd will never start up multipathd even if the service is enabled, and all multipath commands check for a configuration file as soon as they start, and stop if not is present. Once your system is running I don't know of anything that would generate a multipath.conf file. Anaconda does and RHEV does on install, but that should be it. *** This bug has been marked as a duplicate of bug 1160478 *** |