[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"

When you are working with an old xen clone it seems you also have the change 
running an old(er) qemu since it doesn't seem to be auto updated to the commit 
id from the Config.mk

I am not quite following your logic here. Without understanding how it
actually does it, I would presume the logical thing to do is to bring
the repository up to date then checkout the specified commit. This
wouldn't necessarily be the latest commit as you may wish to go back in
time. OTH if it can't checkout the required commit IMHO it should be a
fatal situation because you can end-up in an unknown state (like I did).
Maybe I am misunderstanding what is at work here
Yes it's not very ideal. Since the xen build depends on other git trees 
(seabios, qemu) and these are pulled automatically on the first build after a 
It's not strange to assume that these trees also get updates automatically when 
you update you local xen tree. But it seems to be not a valid assumption :-)

Don't know if it is easy to fix, because it could interfere with the workflow 
of active developers/maintainers i guess.
It seems as if a 'make distclean' removes these repositories whereas make clean doesn't. I think you alluded to this earlier, but I didn't pick up on at the time. Once I did a 'make distclean', my original repository re-cloned what it needed and all was good. I had been using 'make clean'.

The cloning code is in a script:-


if test $# -lt 3; then
        echo "Usage: $0 <tree> <tag> <dir>"
        exit 1


set -e

if test \! -d $DIR-remote; then
        rm -rf $DIR-remote $DIR-remote.tmp
        mkdir $DIR-remote.tmp; rmdir $DIR-remote.tmp
        $GIT clone $TREE $DIR-remote.tmp
        if test "$TAG" ; then
                cd $DIR-remote.tmp
                $GIT branch -D dummy >/dev/null 2>&1 ||:
                $GIT checkout -b dummy $TAG
                cd ..
        mv $DIR-remote.tmp $DIR-remote
rm -f $DIR
ln -sf $DIR-remote $DIR

As far as I can tell does not much if the folder is already there :(

I think I will make a new clone of Xen.
A fresh clone should fix that up since that also pulls a fresh qemu tree in.
Which it did. Thanks again
So after a fresh clone and build of the xen tree your hvm guests now boots 
without problem ?

Yes, that is exactly it. A "make distclean" on my old one also yielded success.

Thanks again for your assistance. A credit to community. :)

Thanks for all your help.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.