Bug 521126

Summary: [qemu netboot] several unnecessary delays during PXE boot
Product: [Fedora] Fedora Reporter: Warren Togami <wtogami>
Component: gpxeAssignee: Matt Domsch <matt_domsch>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: gcosta, matt_domsch
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-08 22:34:54 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Warren Togami 2009-09-03 14:41:58 EDT
The F-12 qemu with gPXE seems to have regressed and added two or three separate
delays during netboot.

+ qemu-kvm -hda /dev/null -boot n -m 256 -net nic,model=rtl8139 -net
tap,script=/usr/sbin/examplebridge-ifup

gPXE (http://etherboot.org) - 00:00.0 C900 PCI2.10 INT19 C900
Press CTRL-B to configure gPXE (PCI 00:00.0)...

*** delay of ~3 seconds ***

Press F12 for boot menu

*** delay of ~2 seconds ***

Press N to skip booting from gPXE (PCI 00:00.1)...

*** delay of ~3 seconds ***

The last prompt, if you press N it seems to skip the delay but it goes ahead
and boots via gPXE anyway.  This prompt seems to be both incorrect and also
with no purpose.

In these cases, you have requested -boot n so why is it second guessing the
user with delays?
Comment 1 Matt Domsch 2009-10-05 23:34:06 EDT
Warren, have you filed this upstream by chance?
Comment 2 Matt Domsch 2009-10-08 22:34:54 EDT
Per upstream, these delays are working as designed.

I recommend you work with upstream if you wish to see a behavior change.  That may include adding an option to disable those delays when booting in a QEMU environment.
Comment 3 Matt Domsch 2009-10-08 22:36:17 EDT
-----Original Message-----
From: Joshua Oreman [mailto:oremanj@rwcr.net]
Sent: Thu 10/8/2009 9:28 AM
To: Domsch, Matt
Cc: etherboot-developers@lists.sourceforge.net
Subject: Re: [Etherboot-developers] [qemu netboot] several unnecessary delays during PXE boot
 
On Mon, Oct 5, 2009 at 11:36 PM,  <Matt_Domsch@dell.com> wrote:
> FYI, Filed in Fedora Bugzilla.  https://bugzilla.redhat.com/show_bug.cgi?id=521126
>
> Description From  Warren Togami (wtogami@redhat.com)  2009-09-03 14:41:58 EDT
>
> The F-12 qemu with gPXE seems to have regressed and added two or three separate
> delays during netboot.

I don't think these are "regressions" compared to anything except
Etherboot, and viewed from the context of a physical ROM in hardware
they're actually improvements. I see how they can be a little annoying
on qemu, but I really don't think a 5-second delay in the boot process
is much worth worrying about. That said, details below, including a
way to remove the delays...

> + qemu-kvm -hda /dev/null -boot n -m 256 -net nic,model=rtl8139 -net
> tap,script=/usr/sbin/examplebridge-ifup
>
> gPXE (http://etherboot.org) - 00:00.0 C900 PCI2.10 INT19 C900
> Press CTRL-B to configure gPXE (PCI 00:00.0)...
>
> *** delay of ~3 seconds ***

This is a hook displayed as soon as the ROM image is initialized,
before POST is complete. On a real system, where one often can't
simply skip loading option ROMs, it is a lifesaver for recovering from
various kinds of flashing issues. I would have permanently broken at
least two network cards by now were it not for this prompt.

The main reason this is included, though, is due to OEM requirements.
See the log for commit 7cd08434ea4ccdbc0414c01eef0af925695f1ee0.

> Press F12 for boot menu
>
> *** delay of ~2 seconds ***

This is the QEMU BIOS, offering you its normal choice now that gPXE
has hooked itself into the boot system.

> Press N to skip booting from gPXE (PCI 00:00.1)...
>
> *** delay of ~3 seconds ***

This is offered because QEMU does not support the BIOS Boot
Specification. On a physical system, gPXE in such an environment has
to hook int 19h, meaning it will always be booted before local drives.
Thus it is important to have a way to skip that for troubleshooting.
See the log for commits 9d44a061885cd81b58cc2d31edd16d60c5d8a3b2 and
4d7c650164a759e3dadbcf8f83da6789165c68b7.

> The last prompt, if you press N it seems to skip the delay but it goes ahead
> and boots via gPXE anyway.  This prompt seems to be both incorrect and also
> with no purpose.

I believe that is a fluke of qemu; I've never heard of the N not
working on a physical system, and the code for that has not changed in
quite a while.

> In these cases, you have requested -boot n so why is it second guessing the
> user with delays?

Because the gPXE ROM loader has to be generic (it can be burned into
network cards at the factory) and it doesn't make any effort to
recognize qemu specifically. qemu only loads the ROM when a network
boot is requested, but a physical system will load it every time, so
gPXE has to provide ways of managing the case where you *don't* want
to network boot. On a remotely modern system with BBS, the "Press N to
skip booting" prompt never shows up, but qemu doesn't emulate a
remotely modern BIOS. I'm not convinced special-casing qemu would be
worth it.

If the delays are causing you great trouble, edit
arch/i386/prefix/romprefix.S and change

#define ROM_BANNER_TIMEOUT ( 2 * ( 18 * BANNER_TIMEOUT ) / 10 )

to

#define ROM_BANNER_TIMEOUT 0

If you want to get rid of the "Press Ctrl-B for the gPXE command
line..." wait too, edit config/general.h and

#define BANNER_TIMEOUT 0

instead of the default 20 (two seconds).

-- Josh
Comment 4 Matt Domsch 2009-10-08 22:37:10 EDT
-----Original Message-----
From: Miller, Shao [mailto:Shao.Miller@yrdsb.edu.on.ca]
Sent: Thu 10/8/2009 6:12 PM
To: Domsch, Matt
Cc: etherboot-developers@lists.sourceforge.net
Subject: RE: [Etherboot-developers] [qemu netboot] several unnecessary delaysduring PXE boot
 
Good day Matt,

In regards to QEmu + gPXE delays and boot order: Thanks for passing that
along.  If Warren is reading this...

I believe that QEmu's '-boot X' argument causes QEmu to attempt to boot
with that device first, then fall back to some other boot order.  Since
you have no other boot devices, I would guess that even when you press
'N' to skip booting gPXE, the QEmu booting fall-back strategy takes a
look and finds nothing else, so executes gPXE anyway.  Also, why are you
pressing 'N' with no other boot devices?

If you'd like to, you could change the delay times in gPXE.  Perhaps
with QEmu, shorter delays might be more appropriate.

As for "second-guessing," gPXE's prompts are designed with many
platforms in mind, including platforms which have other boot devices.
The prompts are offered so that gPXE doesn't completely hijack a system
and rob it of its other boot devices as a possibility.

- Shao Miller