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

Re: [Xen-devel] Booting NetBSD in pygrub

On Sat, 2013-09-07 at 11:56 +0000, M. Boerschig wrote:
> Hi,
> I'm working on NetBSD support in pygrub: I've posted my work on the
> NetBSD port-xen list [1].  It adds support for FFSv2 to tools/libfsimage
> and NetBSD partition/disklabel support to tools/pygrub.
> I started off using xen-unstable and the xl tools on a kernel 3.2, but
> I'm now on xen-4.3 and kernel 3.10.

I think this implies a Linux dom0?

I imagine this is equally broken with a Linux domU, because it doesn't
seem likely to be guest specific, given that it is mostly before the
guest runs...

> Retrieving the kernel and arguments appears to work, but the boot
> process waits for a console escape character before continuing:
>  dom0# pygrub --debug --output-directory=/tmp /dev/mapper/vg00-ffsv2
>  linux (kernel /tmp/boot_kernel.NR37Lm)(args "root=xbd0 ")
>  dom0# md5sum /tmp/boot_kernel.NR37Lm
>  9e492b31e18f7e816f3e374d7f365857  /tmp/boot_kernel.NR37Lm
>  dom0# $XEN/tools/xcutils/readnotes /tmp/boot_kernel.NR37Lm
>  __xen_guest: GUEST_OS=NetBSD,GUEST_VER=4.99,XEN_VER=xen-3.0,LOADER=generic,
>  VIRT_BASE=0xffffffff80000000,ELF_PADDR_OFFSET=0xffffffff80000000,
>  VIRT_ENTRY=0xffffffff80100000,HYPERCALL_PAGE=0x00000101,BSD_SYMTAB=yes
>  dom0# xl create -c ffsv2/config
>  Parsing config from ffsv2/config
>  #XXX here it hangs in a xenconsole until a Control-] is enterted
>  ^]
>  Daemon running with PID 3635
>  Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
>      2006, 2007, 2008, 2009, 2010, 2011, 2012
>      The NetBSD Foundation, Inc.  All rights reserved.
>  Copyright (c) 1982, 1986, 1989, 1991, 1993
>      The Regents of the University of California.  All rights reserved.
>  NetBSD 6.1 (XEN3_DOMU)
>  total memory = 512 MB
>  avail memory = 487 MB
>  mainbus0 (root)
>  hypervisor0 at mainbus0: Xen version 4.3.1-pre
>  [... snip]
>  boot device: xbd0
>  root on xbd0a dumps on xbd0b
>  Your machine does not initialize mem_clusters; sparse_dumps disabled
>  root file system type: ffs
>  /etc/rc.conf is not configured.  Multiuser boot aborted.
>  Enter pathname of shell or RETURN for /bin/sh: /bin/ksh
>  # md5 /netbsd
>  MD5 (/netbsd) = 9e492b31e18f7e816f3e374d7f365857
> I've tracked this issue down to the boot hanging in a xenconsole:
> xenconsoled creates a xenconsole which basically does nothing.
> The boot continues with a new xenconsole after sending a control-].
> I experimented with different boot arguments like "console=hvc0
> xencons=tty" to no avail.
> I'm really clueless about what's wrong.

This stuff ha been a bit fragile in the past, I wouldn't be too
surprised if it had regressed, especially since it isn't especially
amenable to automated testing.

What is supposed to happen is that pygrub gets launched attached to a
pty, and that ptr gets written to xenstore such that the xenconsole
client connects to it and presents the pygrub output to the user as if
it were the guest console, xl acts as a pump copying data back and forth
between the console pty and pygrubs pty (since both console and pygrub
expect to be a slave). Much of this code is in libxl_bootloader.c.

Once pygrub exits this pty disappears and the console client should
reattach to the real guest console pty, which is provided by

It sounds like that first connection is not going to the right place or
is otherwise broken.

Are you seeing the pygrub menu? DO you expect to? Perhaps the automatic
exit of the first session is not working?

The last relevant looking commit to libxl_bootloader.c was
7253e0fd1aeb3ae7d4714bcc1d86b846b3331995 which looks like the sort of
thing which might accidentally introduce such behaviour.

> Any help appreciated.
> [1] http://mail-index.netbsd.org/port-xen/2013/09/02/msg008020.html
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

Xen-devel mailing list



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