If I've got the previous comments right, this was not a QEMU bug, but a
bug in "mount" and the guest kernel ... so closing this QEMU ticket here
now.
** Changed in: qemu
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml,
** Changed in: qemu
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/648128
Title:
VirtFS: Cannot mount 9p during boot
Status in QEMU:
Fix Committed
Bug
Fixed for me by http://article.gmane.org/gmane.linux.utilities.util-
linux-ng/3500/raw and
http://article.gmane.org/gmane.linux.kernel/1041020/raw
** Changed in: qemu
Status: New => In Progress
--
VirtFS: Cannot mount 9p during boot
https://bugs.launchpad.net/bugs/648128
You received this
So it is a problem that pwd inside the root shell is / and thus it finds
/host and informs the kernel that it should mount /host using 9p to /mnt
(which is of course bogus). I am quite unsure how to work around that
problem without a stupid hack in rc.local instead of /etc/fstab
So there is still
Next steps were to use the old envs:
$ for i in USER MAIL OLDPWD HOME HUSHLOGIN PS1 LOGNAME TERM PATH SHELL PWD; do
unset $i; done
$ export CONSOLE=/dev/console
$ export HOME=/
$ export runlevel=2
$ export INIT_VERSION=sysvinit-2.88
$ export COLUMNS=80
$ export TERM=linux
$ export PATH=/sbin:/usr
Important information: There exists a folder /host in the guest
filesystem
--
VirtFS: Cannot mount 9p during boot
https://bugs.launchpad.net/bugs/648128
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: New
Bug descriptio
