Bug 521126
| Summary: | [qemu netboot] several unnecessary delays during PXE boot | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Warren Togami <wtogami> |
| Component: | gpxe | Assignee: | Matt Domsch <matt_domsch> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | 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-09 02:34:54 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Warren Togami
2009-09-03 18:41:58 UTC
Warren, have you filed this upstream by chance? 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. -----Original Message----- From: Joshua Oreman [oremanj] Sent: Thu 10/8/2009 9:28 AM To: Domsch, Matt Cc: etherboot-developers.net Subject: Re: [Etherboot-developers] [qemu netboot] several unnecessary delays during PXE boot On Mon, Oct 5, 2009 at 11:36 PM, <Matt_Domsch> wrote: > FYI, Filed in Fedora Bugzilla. https://bugzilla.redhat.com/show_bug.cgi?id=521126 > > Description From Warren Togami (wtogami) 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 -----Original Message----- From: Miller, Shao [Shao.Miller.on.ca] Sent: Thu 10/8/2009 6:12 PM To: Domsch, Matt Cc: etherboot-developers.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 |