Xen devel - Jul 2010 - [PATCH] rombios: pause for a keypress after a failed boot

rombios: inform the user and pause for a keypress after a failed boot
rather than powering off immediately. 

Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>

diff -r e8f6f9a86f55 tools/firmware/rombios/rombios.c
--- a/tools/firmware/rombios/rombios.c	Tue Jul 06 14:30:39 2010 +0100
+++ b/tools/firmware/rombios/rombios.c	Tue Jul 06 14:42:04 2010 +0100
@@ -8243,7 +8243,27 @@
     write_word(ebda_seg, IPL_BOOTFIRST_OFFSET, 0xFFFF);
     /* Reset boot sequence */
     write_word(ebda_seg, IPL_SEQUENCE_OFFSET, 0xFFFF);
-  } else if (bootdev == 0) BX_PANIC("No bootable device.\n");
+  } else if (bootdev == 0) {
+    printf("\nNo bootable device.\n");
+    printf("Reboot or press any key to retry.");
+    write_word(ebda_seg, IPL_SEQUENCE_OFFSET, 0xFFFF);
+ASM_START
+    sti
+ASM_END
+    {
+      Bit8u sc, ac;
+      while(!dequeue_key(&sc, &ac, 1)) {
+ASM_START
+        hlt
+ASM_END
+      }
+    }
+ASM_START
+    cli
+ASM_END
+    printf("\n\n");
+    return;
+  }
 
   /* Translate from CMOS runes to an IPL table offset by subtracting 1 */
   bootdev -= 1;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> 
> rombios: inform the user and pause for a keypress after a failed boot
> rather than powering off immediately.
> 
That''s a great idea for many situations, but not for all. If the DomU
fails to boot (eg because the drbd backing store is offline or
something) it would be nice to have the domain exit so that monitoring
can kick in and alert someone, rather than it just sitting there in a
running state waiting for user input that might never come.

I know it''s probably a heap more work, but could the behaviour be
driven
by a config file setting? Otherwise this new behaviour is going to be a
regression.

Thanks

James


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 07/07/2010 02:43, "James Harper"
<james.harper@bendigoit.com.au> wrote:
>> rombios: inform the user and pause for a keypress after a failed boot
>> rather than powering off immediately.
>> 
> 
> That''s a great idea for many situations, but not for all. If the
DomU
> fails to boot (eg because the drbd backing store is offline or
> something) it would be nice to have the domain exit so that monitoring
> can kick in and alert someone, rather than it just sitting there in a
> running state waiting for user input that might never come.
> 
> I know it''s probably a heap more work, but could the behaviour be
driven
> by a config file setting? Otherwise this new behaviour is going to be a
> regression.
Simply pausign for a few seconds might be nice. Gives enough time for a user
to see what is going on, but doesn''t leave an unattended VM hanging
around
forever?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> 
> On 07/07/2010 02:43, "James Harper"
<james.harper@bendigoit.com.au>
wrote:
> 
> >> rombios: inform the user and pause for a keypress after a failed
boot
> >> rather than powering off immediately.
> >>
> >
> > That''s a great idea for many situations, but not for all. If
the
DomU
> > fails to boot (eg because the drbd backing store is offline or
> > something) it would be nice to have the domain exit so that
monitoring
> > can kick in and alert someone, rather than it just sitting there in
a
> > running state waiting for user input that might never come.
> >
> > I know it''s probably a heap more work, but could the
behaviour be
driven
> > by a config file setting? Otherwise this new behaviour is going to
be a
> > regression.
> 
> Simply pausign for a few seconds might be nice. Gives enough time for
a user
> to see what is going on, but doesn''t leave an unattended VM
hanging
around
> forever?
> 
That would certainly be much easier in terms of programming effort, and
fulfils most of my concerns.

What criteria does xend use to determine if a domain is in a reboot
loop? Is it just a single restart within some number of seconds, or is
it a certain number of reboots in a certain number of seconds?

Thanks

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 07/07/2010 07:29, "James Harper"
<james.harper@bendigoit.com.au> wrote:
>> Simply pausign for a few seconds might be nice. Gives enough time for
> a user
>> to see what is going on, but doesn''t leave an unattended VM
hanging
> around
>> forever?
>> 
> 
> That would certainly be much easier in terms of programming effort, and
> fulfils most of my concerns.
> 
> What criteria does xend use to determine if a domain is in a reboot
> loop? Is it just a single restart within some number of seconds, or is
> it a certain number of reboots in a certain number of seconds?
I think it''s a single restart within 60 seconds that triggers it.
That''s how
the code reads anyway.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

At 07:26 +0100 on 07 Jul (1278487607), Keir Fraser
wrote:
> > That''s a great idea for many situations, but not for all. If
the DomU
> > fails to boot (eg because the drbd backing store is offline or
> > something) it would be nice to have the domain exit so that monitoring
> > can kick in and alert someone, rather than it just sitting there in a
> > running state waiting for user input that might never come.
> > 
> > I know it''s probably a heap more work, but could the
behaviour be driven
> > by a config file setting? Otherwise this new behaviour is going to be
a
> > regression.
> 
> Simply pausign for a few seconds might be nice. Gives enough time for a
user
> to see what is going on, but doesn''t leave an unattended VM
hanging around
> forever?
That''s easy enough.  The attached patch makes it wait 30 seconds before
shutting down instead.  (It applies on top of my original patch).

Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>

Tim.

-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel