On Sun, Jul 31, 2011 at 10:26 AM, Dave Reisner <d@xxxxxxxxxxxxxx> wrote:
>> I have an arch linux install running in qemu using a 9p virtual root
>> filesystem (root filesystem is just a sub directory on the host).
>>
>> This is the line I use to launch it:
>>
>> qemu-system-x86_64 -enable-kvm -virtfs
>> local,path=$(pwd)/wn-root,security_model=mapped,mount_tag=wn-root -smp
>> 2 -m 1024 -kernel ./wn-root/boot/vmlinuz26 -append 'rootfstype=9p
>> rootflags="trans=virtio,version=9p2000.L" root=wn-root ro
>> rootdelay=10' --initrd ./wn-root/boot/kernel26-fallback.img -net vde
>> -net nic,vlan=0,macaddr=52:54:00:00:EE:03
>>
>> Immediately after "::Running Hook [resume]" though I get:
>>
>> Root device 'wn-root' does'nt exist. Attempting to create it.
>> ERROR: Unable to determine major/minor number of root device 'wn-root'.
>>
>> At that point I'm dropped into the recovery shell, I exit that, it
>> complains, but continues to boot fine as it the existence in /dev/ of
>> a 9p filesystem source is not needed.
>>
>> I did not find anything in mkinitcpio.conf to disable this check,
>> which in this case is not needed, as the root filesystem is mounted
>> without any problem.
>>
>> Using 9p for a kvm root filesystem is useful for cases where something
>> like Linux containers (LXC) is not sufficient to accomplish some task.
>>
>> For the most part this is working fine, still have some 9p filesystem
>> oddities to work through. For instance, syslog-ng won't start and
>> using makepkg on some packages results in "cat: -: No such file or
>> directory" (that error does not occur when that arch install is
>> chrooted into and build run from inside the chroot). The 9p issues are
>> not relevant to the initcpio workaround I'm looking for though.
>>
>> Dwight
>
> You'll likely want to create your own mount handler as this is a bit of
> an edge case. Doesn't need to be anything complex..
>
> 9p_mount_handler() {
> mount -t 9p -o ro,${rootflags} "$root" "$1"
> }
> mount_handler=9p_mount_handler
>
> This gets added to /lib/initcpio/hooks (call it 9p?) and then wrapped up
> in a build script which is added to /lib/initcpio/install. After that,
> add '9p' to your HOOKS in the config. Note that while the install
> scripts are interpreted by /bin/bash, hooks that run on the initcpio are
> interpreted by /bin/busybox ash.
>
> dave
>
Alright, I did that, but it is still doing the root device check and
dropping into the recovery shell, so I have to press Ctrl-D to
continue.
>From /etc/mkinitcpio.conf:
MODULES="" # I was putting the modules here, now they are in install/9p
HOOKS="base udev autodetect 9p filesystems"
----< start /lib/initcpio/hooks/9p >----
run_hook () {
modprobe 9p
modprobe 9pnet
modprobe fscache
modprobe virtio
modprobe virtio_ring
modprobe virtio_pci
modprobe 9pnet_virtio
}
9p_mount_handler() {
mount -t 9p -o ro,${rootflags} "$root" "$1"
}
mount_handler=9p_mount_handler
----< end /lib/initcpio/hooks/9p >----
----< start /lib/initcpio/install/9p >----
#!/bin/bash
build() {
MODULES+=" 9p 9pnet fscache virtio virtio_ring virtio_pci 9pnet_virtio"
}
help() {
cat<<HELPEOF
This hook allows a 9p virtual filesystem passthrough to be used
as the root filesystem when run qemu KVM.
HELPEOF
}
----< end /lib/initcpio/install/9p >----
It does not seem to matter where I put the 9p hook in the HOOKS string
before rebuilding the initcpio images.
Dwight
