Description of problem: 9pfs is a way to share host disks with guests running on KVM unfortunately, boot fails if I try to add a 9pfs mount in guest probably because it needs 9pnet_virtio to actually work and that is not in initramfs. Version-Release number of selected component (if applicable): dracut-034-64.git20131205.fc20.x86_64 How reproducible: always Steps to Reproduce: 1. install fedora to disk in a VM I used these commands wget http://download.fedoraproject.org/pub/fedora/linux/releases/20/Live/x86_64/Fedora-Live-Desktop-x86_64-20-1.iso you install qemu-kvm qemu-img create -f qcow2 f20-x64.qcow2 40G qemu-kvm -enable-kvm -m 1g -cpu kvm64 -smp 2 f20-x64.qcow2 -netdev user,id=foo -redir tcp:8022::22 -device virtio-net,netdev=foo -serial stdio -fsdev local,security_model=none,id=fsdev0,path=/ -device virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=hostshare -monitor stdio -cdrom Fedora-Live-Desktop-x86_64-20-1.iso 2. follow prompts to complete fedora 20 installation to disk 3. log into guest. mkdir /hostshare add this to /etc/fstab hostshare /hostshare 9p trans=virtio,version=9p2000.L 0 0 4. reboot guest Actual results: boot fails, dracut outputs errors about failure to mount /hostshare Expected results: boot succeeds Additional info: - adding 9pnet_virtio to initramfs might help. did not try yet. - is there a way to tell dracut to ignore failed mounts? I can suppress mount errors with nofail, but a warning would have been nicer. - Note I added a mount point not necessary for boot at all. How about retrying mount once before prompting user? Assuming first mount did mount /lib/modules anything missing in initramfs will now be available. It would have helped in this case.
are you sure this is "dracut" wanting to mount /hostshare? Normally dracut only mounts / and /usr from fstab. I guess, this is systemd. Can you attach some logs? # journalctl -b -o short-monotonic
I think we could close as dup of 1184122 (or the other way around if you prefer)
*** This bug has been marked as a duplicate of bug 1184122 ***
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days