Adding a virtio 9p mount in /etc/fstab such as: bootshare /share/boot 9p trans=virtio,version=9p2000.L 0 0 and the corresponding qemu arguments, guest fails at boot with the following dmesg error: "9pnet: Could not find request transport: virtio" After logging in emergency mode, lsmod shows that 9pnet_virtio is loaded and further manual mount just works. Some people workaround or solve the issue by regenerating initramfs to include 9pnet_virtio, see also this thread: https://lists.gnu.org/archive/html/qemu-devel/2014-02/msg00116.html However, it looks like a race between module loading and mount time.
It still doesn't work even if all the 9pnet/virtio the modules are in the initramfs in /lib/modules/xxxxx. A workaround is to use the systemd automount facility, for example: host qemu command line: -virtfs "local,path=/path/to/shared/dir,mount_tag=host0,security_model=none,id=host0" -device "virtio-9p-pci,fsdev=host0,mount_tag=host0" in guest /etc/fstab: host0 /mnt/shared 9p x-systemd.automount,x-systemd.device-timeout=10,trans=virtio,version=9p2000.L,rw 0 0 But whatever causes the bug should really get fixed, because if the modules are present in /lib/modules in the initramfs, there's no reason that they shouldn't be found.
systemd is not involved in module loading triggered by mounts. That is done by the kernel on its own, by requiesting the modules from kmod. Most likely some of the kernel modules involved are lacking the right module dependency macros. Reassigning to kernel.
Could someone attach the full dmesg output?
journalctl -b -o short-monotonic ... [ 8.085934] f21-test systemd-journal[446]: Time spent on flushing to /var is 66.906ms for 545 entries. [ 8.088175] f21-test kernel: FS-Cache: Loaded [ 8.159684] f21-test kernel: 9pnet: Installing 9P2000 support [ 8.357616] f21-test kernel: 9p: Installing v9fs 9p2000 file system support [ 8.357663] f21-test kernel: FS-Cache: Netfs '9p' registered for caching [ 8.359250] f21-test kernel: 9pnet: Could not find request transport: virtio [ 8.552982] f21-test kernel: Installing knfsd (copyright (C) 1996 okir.de). [ 8.796919] f21-test alsactl[506]: alsactl 1.0.28 daemon started [ 8.797142] f21-test alsactl[506]: /usr/sbin/alsactl: load_state:1729No soundcards found... [ 8.798139] f21-test systemd-udevd[492]: starting version 216 [ 8.798583] f21-test systemd[1]: home-elmarco-src.mount mount process exited, code=exited status=32 [ 8.798713] f21-test systemd[1]: Failed to mount /home/elmarco/src. [ 8.798813] f21-test systemd[1]: Dependency failed for Local File Systems. [ 8.798912] f21-test systemd[1]: Dependency failed for Relabel all filesystems, if necessary. [ 8.799459] f21-test systemd[1]: Dependency failed for Mark the need to relabel after reboot. [ 8.799762] f21-test systemd[1]: Unit home-elmarco-src.mount entered failed state. [ 8.799828] f21-test lvm[455]: 2 logical volume(s) in volume group "fedora" monitored [ 8.801024] f21-test mount[493]: mount: wrong fs type, bad option, bad superblock on src, [ 8.801066] f21-test mount[493]: missing codepage or helper program, or other error [ 8.801094] f21-test mount[493]: (for several filesystems (e.g. nfs, cifs) you might [ 8.801121] f21-test mount[493]: need a /sbin/mount.<type> helper program) [ 8.801148] f21-test mount[493]: In some cases useful info is found in syslog - try [ 8.801175] f21-test mount[493]: dmesg | tail or so. [root@f21-test ~]# uname -a Linux f21-test 4.0.0-rc5-virtio-gpu+ #10 SMP Wed Mar 25 17:58:25 CET 2015 x86_64 x86_64 x86_64 GNU/Linux
*** Bug 1062981 has been marked as a duplicate of this bug. ***
I skimmed net/9p/ very superficially. It seems to have a plugin system where the common code avoids having any build-time dependency on the plugins (ie. transports) on purpose. See eg. one of the very early commits, commit a80d923e1321a7ed69a0918de37e39871bb536a0 Author: Eric Van Hensbergen <ericvh@opteron.(none)> Date: Wed Oct 17 14:31:07 2007 -0500 9p: Make transports dynamic This patch abstracts out the interfaces to underlying transports so that new transports can be added as modules. This should also allow kernel configuration of transports without ifdef-hell. Signed-off-by: Eric Van Hensbergen <ericvh> The plugin / transport system also (or, more precisely, "accordingly") doesn't make use of the EXPORT_SYMBOL() macros that depmod could utilize. I even think, from the source in "client.c", that if you created a working virtio transport for 9p, you could still unload the virtio transport module from under the generic code, and stuff would just crash. I don't see reference tracking (but I may have missed it as well, of course -- this is the first look I've ever taken at it). If the above plugin system has been the intent, ie. the common code only wants to look at plugins that are already there, and not depend on / require any transports, then the transports have to be loaded *before* the mount unit is processed. (Which is actually what happens in comment 1; the mount is just delayed long enough.) Of course, the common 9p code could make an *attempt* to preload its available transports, but for that it would either have to know the names of the transports (which conflicts with the original, presumed, intent), or to enumerate the available transport types in the appropriate kernel module directory (which would probably be more appropriate to implement outside of the kernel, like a separate, high-priority systemd unit -- no clue).
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 21 kernel bugs. Fedora 21 has now been rebased to 3.19.5-200.fc21. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 22, and are still experiencing this issue, please change the version to Fedora 22. If you experience different issues, please open a new bug report for those.
Last checked with Linux f21-test 4.0.0-rc5, probably still unfixed in f22, moving
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 22 kernel bugs. Fedora 22 has now been rebased to 4.2.3-200.fc22. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 23, and are still experiencing this issue, please change the version to Fedora 23. If you experience different issues, please open a new bug report for those.
This is working correctly in Fedora 24 with kernel: 4.5.2-302.fc24.x86_64 #1 SMP Wed Apr 27 14:22:29 UTC 2016 The following snippet is from 'virsh dumpxml <domain>': <filesystem type='mount' accessmode='passthrough'> <source dir='/home/david/Code/git/private/local/poc'/> <target dir='poc'/> <alias name='fs0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </filesystem> The '/etc/fstab' file in the guest contains: poc /home/devel/poc 9p trans=virtio,version=9p2000.L 0 0 Systemd reports the unit as active as well: [root@devel ~]# systemctl status home-devel-poc.mount ● home-devel-poc.mount - /home/devel/poc Loaded: loaded (/etc/fstab; bad; vendor preset: disabled) Active: active (mounted) since Mon 2016-05-02 21:52:28 BST; 10min ago Where: /home/devel/poc What: poc Docs: man:fstab(5) man:systemd-fstab-generator(8) Process: 724 ExecMount=/usr/bin/mount poc /home/devel/poc -t 9p -o trans=virtio,version=9p2000.L (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 512) May 02 21:52:28 devel.multicats.virtual systemd[1]: Mounting /home/devel/poc... May 02 21:52:28 devel.multicats.virtual systemd[1]: Mounted /home/devel/poc. Creating/removing files works as expected. The user in the guest VM and the user in the host whom files are being shared, have the same UID,GID and SELinux user.
Broken again when updating to: Install qemu-common-2:2.6.0-0.2.rc4.fc24.x86_64 @updates-testing Install qemu-img-2:2.6.0-0.2.rc4.fc24.x86_64 @updates-testing Install qemu-kvm-2:2.6.0-0.2.rc4.fc24.x86_64 @updates-testing Install qemu-system-x86-2:2.6.0-0.2.rc4.fc24.x86_64 @updates-testing The mount point is present, but the contents cannot be listed, even as root, in the guest. The error shown is: ls: cannot open directory '.': Permission denied
Permission problems are due to SELinux restrictions. The shared content has to be accessible from svirt_t. 'sesearch' can be used to find a suitable type, I have used 'nfs_t', as that is the type used in the guest as well. To summarize, a working example: - XML config <filesystem type='mount' accessmode='passthrough'> <source dir='/home/david/Shared'/> <target dir='poc'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </filesystem> - Guest '/etc/fstab' poc /home/devel/Shared 9p trans=virtio,version=9p2000.L 0 0 - SELinux labeling on the host ('chcon' recursively, or add via 'semanage fcontext'): [user@host ~]$ ls -lrtdZ Shared drwx------. 6 david david unconfined_u:object_r:nfs_t:s0 161 May 6 17:07 Shared/ - SELinux context on the guest (automatic): [devel@guest ~]$ ls -lrtdZ Shared/ drwx------. 6 devel devel system_u:object_r:nfs_t:s0 161 May 6 17:07 Shared/ For reference, currently installed SELinux targeted policy RPM version is: selinux-policy-targeted-3.13.1-184.fc24.noarch
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Reopening. Can anyone confirm if this issue is fixed somehow. Maybe in selinux-policy? Reassigning due to comment #12.
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'.
openssh-7.2p2-11.fc24 selinux-policy-3.13.1-191.8.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-99191c4aab
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.