On Sun, Jul 31, 2011 at 3:56 PM, Dave Reisner
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 }
FYI, you can run:
modprobe -a 9p 9pnet fscache ..
and save yourself some forks.
Thanks.
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<
---- It does not seem to matter where I put the 9p hook in the HOOKS string before rebuilding the initcpio images.
Dwight
My fault for suggesting a rotten name. You can't start a function name with a number.
$ 9p() { echo hi; } ash: syntax error: bad function name
Parsing failed on sourcing the hook, and mount_handler was never declared. Rename the function to something that ash plays nicely with and you should get some joy.
dave
Ok, I renamed "9p_mount_handler" to "ninep_mount_handler" and updated mount_handler= accordingly, and rebuild the initcpio images. Still no joy... :) I went so far as to rename 9p to ninep in /lib/initcpio/{install,hooks} and the HOOKS string, and rebuilt the initcpio images, but that did not help. Dwight