From mboxrd@z Thu Jan 1 00:00:00 1970 From: "M. Boerschig" Subject: Re: Booting NetBSD in pygrub Date: Fri, 13 Sep 2013 18:00:17 +0000 Message-ID: <523352B1.5000702@boerschig.net> References: <522B1482.4010805@boerschig.net> <1378730123.19967.106.camel@kazak.uk.xensource.com> <522E0AEC.1@boerschig.net> <1378803369.21748.25.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1378803369.21748.25.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: xen-devel@lists.xen.org. List-Id: xen-devel@lists.xenproject.org On 09/10/13 08:56, Ian Campbell wrote: > On Mon, 2013-09-09 at 19:52 +0200, M. Boerschig wrote: >> On 09/09/13 14:35, Ian Campbell wrote: >>> On Sat, 2013-09-07 at 11:56 +0000, M. Boerschig wrote: >>> I think this implies a Linux dom0? >> >> Yes, of course. I didn't even get a recent xen (> 4.2) to compile on my >> NetBSD machine. >> >>> >>> 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... >>> >> >> An Ubuntu domU works on this same machine, so I think this problem is >> limited to my use case (or a similar one, like solaris) > > In this case do you get the interactive menu? I wonder if passing > bootloader_args = ["--entry=0"] would reproduce the same error you are > seeing by skipping the menu and making it behave like sniff_solaris? > This triggers exactly the same error as with booting a netbsd domU. I tested this also on a Ubuntu 13.04 dom0 with an unmodified stable-4.3 (4.3.1-pre) on a different machine (with another 13.04 domU), just to make sure it's nothing I broke. So either this problem is specific to debian(-derived) systems or a generic problem with libxl. >>> 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 >>> xenconsoled. >>> >>> 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? >> >> No, and I didn't expect a menu to appear. >> I assumed a menu is only displayed if the run_grub()-method succeeds in >> finding a valid GRUB menu.lst/config on the disk. >> I used the sniff_solaris() code as a guideline: if I understand the code >> correctly it just returns a configuration dictionary without displaying >> anything. > > OK. > >>> The last relevant looking commit to libxl_bootloader.c was >>> 7253e0fd1aeb3ae7d4714bcc1d86b846b3331995 which looks like the sort of >>> thing which might accidentally introduce such behaviour. >> >> Thanks for the pointer, I'll investigate if pygrub's exit is properly >> handled later this week. > > Great, please let us know how you get on! I did have less time than anticipated to familiarize with libxl, as I'm quite busy studying for an exam ... However, I did some debugging and the libxl_aoutils.c:datacopier_pollhup_handled() never received a POLLHUP event, although execution goes through libxl_bootloader.c:bootloader_finished(). Maybe someone more knowledgable about libxl might want a look at this. > > Ian. > >