From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Murray Subject: Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional" Date: Sat, 29 Jun 2013 22:07:16 +0100 Message-ID: <51CF4C84.7050406@yahoo.co.uk> References: <51CE3952.6040704@yahoo.co.uk> <8D86156381FC4D583E0636A5@nimrod.local> <51CEBBC2.3050007@yahoo.co.uk> <51CEC5F2.3030909@yahoo.co.uk> <787625573.20130629143628@eikelenboom.it> <51CED76C.9050201@yahoo.co.uk> <1011217449.20130629151305@eikelenboom.it> <51CEF04D.1000808@yahoo.co.uk> <956778643.20130629164038@eikelenboom.it> <51CF0F21.5070606@yahoo.co.uk> <1559303876.20130629223447@eikelenboom.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1559303876.20130629223447@eikelenboom.it> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Sander Eikelenboom Cc: Stefano Stabellini , Ian Campbell , Alex Bligh , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org 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 clone. > 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:- #!/bin/sh if test $# -lt 3; then echo "Usage: $0 " exit 1 fi TREE=$1 TAG=$2 DIR=$3 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 .. fi mv $DIR-remote.tmp $DIR-remote fi 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. > >