Red Hat Bugzilla – Bug 1017428
multipathd does not start in dracut
Last modified: 2013-11-06 12:48:14 EST
Description of problem: Following test day instructions: https://fedoraproject.org/wiki/QA:Testcase_Virtualization_URL_Guest_Install, virt-install part % sudo virt-install --name test-day-vm --ram 2048 \ --disk path=/var/lib/libvirt/images/test-day-vm.img,size=10 \ --location http://download.fedoraproject.org/pub/fedora/linux/development/20/x86_64/os/ When the image is booted, boot fails in dracut, with multipathd.service failing to start. Screenshot attached. How reproducible: Doing 'systemctl start multipathd' fails immediately every time ("Job for multipathd.service failed. See..."). Starting /usr/sbin/multipathd works fine.
Do you have an /etc/multipath.conf in your initramfs? systemd won't start multipathd unless that file exists. The only other check is that the kernel cmdline doesn't include "nompath" After you start and stop multipathd once, does # systemctl start multipathd then work?
(In reply to Ben Marzinski from comment #1) > Do you have an > > /etc/multipath.conf Yes: $ cat /etc/multipath.conf defaults { find_multipaths yes user_fiendly_names yes } > in your initramfs? systemd won't start multipathd unless that file exists. It starts fine by hand, so I don't think this file is a problem. > The only other check is that the kernel cmdline doesn't include "nompath" $ cat /proc/cmdline method=http://download.fedoraproject.org/pub/fedora/linux/development/20/x86_64/os/ > After you start and stop multipathd once, does > > # systemctl start multipathd > > then work? No.
Oh, stupid, stupid me: it's ExecStartPre=/sbin/modprobe dm-multipath that's failing. # /sbin/modprobe dm-multipath # echo $? 1 Investigating further... # uname -r 3.11.3-301.fc20.x86_64 # ls /lib/modules 3.11.2-301.fc20.x86_64 So, this is a mismatch between the initrd.img and the kernel. Reassigning to virt-install. I tried now again, and this time the downloaded initrd.img and kernel match one another. So this was probably just bad timing on my part, when virt-install downloaded from a partially updated mirror.
Yeah not sure there's anything to do about that in virt-install. I'm going to update the test cases to not point to download.fedoraproject.org, since that link does automagic mirror redirection, so you might end up fetching packages from different mirrors which may be in different states.