[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Booting NetBSD in pygrub
On Fri, 2013-09-13 at 18:00 +0000, M. Boerschig wrote: > 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. Probably generic 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 J (cc-d) knows all about POSIX semantics i.e. when POLLHUP can and should be received etc, I think I might leave this one to him ;-) > > > > > > Ian. > > > > > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |