Bug 810227

Summary: Support 9p filesystem
Product: [Fedora] Fedora Reporter: Oliver Henshaw <oliver.henshaw>
Component: dracutAssignee: dracut-maint
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: buytenh, dracut-maint, harald, jonathan
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-07-03 08:08:09 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:
Attachments:
Description Flags
Proposed dracut virtfs module. none

Description Oliver Henshaw 2012-04-05 12:24:27 UTC 
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):

dracut-013-20.fc16.noarch
Comment 1 Lennert Buytenhek 2012-04-11 01:07:52 UTC 
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 16:54:29 UTC 
I've sent a newer version of this patch to the initramfs@ mailing list:

    http://www.spinics.net/lists/linux-initramfs/msg02529.html

Further discussion should probably take place there.