On 5/27/2010, "Mick Russom" <mickrussom%gmail.com@localhost> wrote:This has been fixed in the latest version in the mercurial repositories.
>6A) gsed is needed
>
>( I used a dirty hack of aliasing sed to gsed, solved the problem with
>
>-Ttext $(RELOC) -o
>
>RELOC is set in xen/arch/x86/boot/Makefile to $(BOOT_TRAMPOLINE), which is
>also set in that file:
>
>BOOT_TRAMPOLINE := $(shell sed -n
>'s,^\#define[[:space:]]\+BOOT_TRAMPOLINE[[:space:]]\+,,p'
>$(BASEDIR)/include/asm-x86/config.h)
No need for gsed.
netbsd HEAD branch has strnlen, so at least it's not a problem with
>6B) second but, strnlen is needed by a considerable number of the utilities:
netbsd HEAD.
I didn't encounter this, but I'm using HEAD, and I don't have an X
>6C) Horrible X11 linking mess for building
server, but I have specifIed X11_TYPE=modular in /etc/mk.conf
Okay, this is due to the fact that you have xentools33 and make
>6D) FATAL:
>
>-msse2: not found
>
>cc1: warnings being treated as errors
>
>xen/lowlevel/xc/xc.c: In function 'pyxc_vcpu_setaffinity':
dist-tools incorrectly uses the 3.3 version of the python Xen headers
instead. I just moved the xen related stuff from /usr/pkg/lnclude to
some other directory and it compiled fine.
I think I have a similar problem. When I use the /usr/mdec/boot 5.2,
>FATAL:
>
>Xen4.0.0 crashes when loading the netbsd XEN3_DOM0 kernel. It doesn't even
>give a (XEN) output or stop and panic. It simply reboots the machine while
>loading netbsd from mboot.c32.
>
which comes with netbsd 5.0 and do 'multiboot xen40.gz' from boot
command line, I would very briefly see the progress number of bytes
loaded and then the screen went blank for a short time. Afterwards the
computer just reboots.
If you try 'multiboot xen.gz' (from xenkernel33) you would get some
additional messages and the computer will halt and report that no dom0
kernel was specified. Is this a problem of grub vs multiboot?
Christoph, did you see this as well?
Thanks,
Toby