Bug 810227 - Support 9p filesystem
Support 9p filesystem
Product: Fedora
Classification: Fedora
Component: dracut (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: dracut-maint
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-04-05 08:24 EDT by Oliver Henshaw
Modified: 2012-07-03 04:08 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-07-03 04:08:09 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Proposed dracut virtfs module. (1.33 KB, application/x-bzip2)
2012-04-10 21:07 EDT, Lennert Buytenhek
no flags Details

  None (edit)
Description Oliver Henshaw 2012-04-05 08:24:27 EDT
Description of problem:

I added a 9p filesystem to a virtual machine in order to share host files with the guest - as described in http://www.linux-kvm.org/page/9p_virtio. Mounting it on the command line works, adding it to /etc/fstab with 'noauto,comment=systemd.automount' works, but simply adding it to /etc/fstab (and mounting it and running mkinitrd) causes boot to fail into a rescue shell.

From dmesg:

[    4.065929] 9p: Installing v9fs 9p2000 file system support
[    4.065978] FS-Cache: Netfs '9p' registered for caching
[    4.067406] 9pnet: Could not find request transport: virtio
[    4.067458] 9pnet: Could not find request transport: virtio
[    4.067984] mount[365]: mount: wrong fs type, bad option, bad superblock on /host-image-destination,
[    4.067990] mount[365]: missing codepage or helper program, or other error
[    4.067993] mount[365]: (for several filesystems (e.g. nfs, cifs) you might
[    4.067996] mount[365]: need a /sbin/mount.<type> helper program)
[    4.067999] mount[365]: In some cases useful info is found in syslog - try
[    4.068020] mount[365]: dmesg | tail  or so

# lsinitrd | grep 9p
drwxr-xr-x   2 root     root            0 Apr  5 13:10 run/initramfs/lib/modules/3.3.0-4.fc16.x86_64/kernel/fs/9p
-rwxr--r--   1 root     root        87168 Mar 20 18:31 run/initramfs/lib/modules/3.3.0-4.fc16.x86_64/kernel/fs/9p/9p.ko
drwxr-xr-x   2 root     root            0 Apr  5 13:10 run/initramfs/lib/modules/3.3.0-4.fc16.x86_64/kernel/net/9p
-rwxr--r--   1 root     root       115536 Mar 20 18:32 run/initramfs/lib/modules/3.3.0-4.fc16.x86_64/kernel/net/9p/9pnet.ko

So 9p is already in the initramfs, just the transport is missing.

After I regenerated the initramfs with "mkinitrd -f /boot/initramfs-`uname -r`.img `uname -r` --with 9pnet_virtio" everything worked as expected.

Version-Release number of selected component (if applicable):

Comment 1 Lennert Buytenhek 2012-04-10 21:07:52 EDT
Created attachment 576636 [details]
Proposed dracut virtfs module.

I whipped up a quick dracut virtfs module (attached, against current F17 dracut) that seems to work for me, i.e. I can boot with / being on 9pnet_virtio.  Specify the volume to attach as root=virtfs:foobar, where 'foobar' is the 9p virtio mount tag.

This module only handles the special case of 9p over virtio (i.e. virtfs), and doesn't attempt to handle mounting 9p filesystems over TCP/IP, for example.

This module should probably have a hostonly mode check added, and I'm not really happy about the level of duplication between mount-virtfs.sh and 95rootfs-block/mount-root.sh, but let's just throw this out there now for some feedback.
Comment 2 Lennert Buytenhek 2012-04-16 12:54:29 EDT
I've sent a newer version of this patch to the initramfs@ mailing list:


Further discussion should probably take place there.

Note You need to log in before you can comment on or make changes to this bug.