Bug 810227 - Support 9p filesystem
Summary: Support 9p filesystem
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: dracut-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-05 12:24 UTC by Oliver Henshaw
Modified: 2012-07-03 08:08 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-07-03 08:08:09 UTC
Type: Bug
Embargoed:


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

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.


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