On 5/27/2010, "Mick Russom" <
mickrussom%gmail.com@localhost> wrote:
>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)
This has been fixed in the latest version in the mercurial repositories.
No need for gsed.
>6B) second but, strnlen is needed by a considerable number of the utilities:
netbsd HEAD branch has strnlen, so at least it's not a problem with
netbsd HEAD.
>6C) Horrible X11 linking mess for building
I didn't encounter this, but I'm using HEAD, and I don't have an X
server, but I have specifIed X11_TYPE=modular in /etc/mk.conf
>6D) FATAL:
>
>-msse2: not found
>
>cc1: warnings being treated as errors
>
>xen/lowlevel/xc/xc.c: In function 'pyxc_vcpu_setaffinity':
Okay, this is due to the fact that you have xentools33 and make
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.
>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.
>
I think I have a similar problem. When I use the /usr/mdec/boot 5.2,
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