[arch-general] iniitcpio root device check
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
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
On Sun, Jul 31, 2011 at 10:26 AM, Dave Reisner <d@falconindy.com> 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
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.
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
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
On Sun, Jul 31, 2011 at 3:56 PM, Dave Reisner <d@falconindy.com> wrote:
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<<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
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
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
Let's try this one more time. You're missing a pointer to your install script. Part of the build function needs: SCRIPT=ninep or whatever you're calling it... d
participants (2)
-
Dave Reisner
-
Dwight Schauer