* [Qemu-devel] Need a way disable gPXE boot
@ 2009-11-18 18:11 Theodore Ts'o
2009-11-18 19:53 ` Anthony Liguori
2009-11-18 20:19 ` [Qemu-devel] " Sebastian Herbszt
0 siblings, 2 replies; 9+ messages in thread
From: Theodore Ts'o @ 2009-11-18 18:11 UTC (permalink / raw)
To: qemu-devel, kvm-devel
I recently updated to the latest qemu-kvm git tree (commit c04b2ae) and
I ran into the following problem. I want to do a direct Linux boot for
some of my testing work, using the -kernel option. Apparently the the
gPXE boot code corrupts something in memory or other CPU state which
causes the loaded kernel to hang after the gPXE code gives up. I can
suppress this using -net none, but of course then I don't have any
networking access.
I was ultimately able to work around the solution by deleting the
/usr/local/share/qemu/pxe-*.bin files, but that's a bit of a botch. It
would be nice if there was a way to disable the gPXE boot option roms;
if you know you are booting off of a passed in hard drive image or
passed in a kernel for a direct boot, there's no reason why we might
want to do a gPXE boot.
It would be nice if there was a way to disable option roms automatically
if -kernel is specified, or if -boot order doesn't include 'n', or
perhaps with an explicit option to suppress all boot option roms (or all
networking options).
What sort of approach would be considered acceptable? Did I miss
some way of making the right thing happen other than deleting the
installed pxe-*.bin files?
Thanks,
- Ted
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] Need a way disable gPXE boot
2009-11-18 18:11 [Qemu-devel] Need a way disable gPXE boot Theodore Ts'o
@ 2009-11-18 19:53 ` Anthony Liguori
2009-11-18 22:37 ` tytso
2009-11-18 20:19 ` [Qemu-devel] " Sebastian Herbszt
1 sibling, 1 reply; 9+ messages in thread
From: Anthony Liguori @ 2009-11-18 19:53 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: kvm-devel, qemu-devel
Hi Ted,
Theodore Ts'o wrote:
> I recently updated to the latest qemu-kvm git tree (commit c04b2ae) and
> I ran into the following problem. I want to do a direct Linux boot for
> some of my testing work, using the -kernel option. Apparently the the
> gPXE boot code corrupts something in memory or other CPU state which
> causes the loaded kernel to hang after the gPXE code gives up. I can
> suppress this using -net none, but of course then I don't have any
> networking access.
>
> I was ultimately able to work around the solution by deleting the
> /usr/local/share/qemu/pxe-*.bin files, but that's a bit of a botch. It
> would be nice if there was a way to disable the gPXE boot option roms;
> if you know you are booting off of a passed in hard drive image or
> passed in a kernel for a direct boot, there's no reason why we might
> want to do a gPXE boot.
>
> It would be nice if there was a way to disable option roms automatically
> if -kernel is specified, or if -boot order doesn't include 'n', or
> perhaps with an explicit option to suppress all boot option roms (or all
> networking options).
>
> What sort of approach would be considered acceptable? Did I miss
> some way of making the right thing happen other than deleting the
> installed pxe-*.bin files?
>
We just did a flag day and switched our PXE rom and BIOS. We've
encountered a few regressions and we're quickly fixing them.
Alex Graf has already fixed the problem you describe above properly and
I've merged that into upstream qemu. It will take a little bit of time
for Avi and/or Marcelo to sync those changes into qemu-kvm.
For now, using '-bios pcbios.bin' should be a reasonable work around.
Regards,
Anthony Liguori
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Qemu-devel] Re: Need a way disable gPXE boot
2009-11-18 18:11 [Qemu-devel] Need a way disable gPXE boot Theodore Ts'o
2009-11-18 19:53 ` Anthony Liguori
@ 2009-11-18 20:19 ` Sebastian Herbszt
2010-03-09 14:11 ` Richard W.M. Jones
1 sibling, 1 reply; 9+ messages in thread
From: Sebastian Herbszt @ 2009-11-18 20:19 UTC (permalink / raw)
To: Theodore Ts'o, qemu-devel, kvm-devel
Theodore Ts'o wrote:
[snip]
> I was ultimately able to work around the solution by deleting the
> /usr/local/share/qemu/pxe-*.bin files, but that's a bit of a botch. It
> would be nice if there was a way to disable the gPXE boot option roms;
> if you know you are booting off of a passed in hard drive image or
> passed in a kernel for a direct boot, there's no reason why we might
> want to do a gPXE boot.
>
> It would be nice if there was a way to disable option roms automatically
> if -kernel is specified, or if -boot order doesn't include 'n', or
> perhaps with an explicit option to suppress all boot option roms (or all
> networking options).
>
> What sort of approach would be considered acceptable? Did I miss
> some way of making the right thing happen other than deleting the
> installed pxe-*.bin files?
I would suggest dropping the auto nic option rom loading and extend "-net"
with a rom option like "-net nic,model=e1000,rom=pxe-e1000.bin".
- Sebastian
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] Need a way disable gPXE boot
2009-11-18 19:53 ` Anthony Liguori
@ 2009-11-18 22:37 ` tytso
0 siblings, 0 replies; 9+ messages in thread
From: tytso @ 2009-11-18 22:37 UTC (permalink / raw)
To: Anthony Liguori; +Cc: qemu-devel, kvm
On Wed, Nov 18, 2009 at 01:53:42PM -0600, Anthony Liguori wrote:
> We just did a flag day and switched our PXE rom and BIOS. We've
> encountered a few regressions and we're quickly fixing them.
>
> Alex Graf has already fixed the problem you describe above properly
> and I've merged that into upstream qemu. It will take a little bit
> of time for Avi and/or Marcelo to sync those changes into qemu-kvm.
Great, thanks! Good to know it's been fixed upstream. I have a
workaround that works for now, and I can wait for Avi or
Marcelo the get those changes merged into qemu-kvm.
- Ted
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] Re: Need a way disable gPXE boot
2009-11-18 20:19 ` [Qemu-devel] " Sebastian Herbszt
@ 2010-03-09 14:11 ` Richard W.M. Jones
2010-03-10 2:03 ` Kevin O'Connor
2010-03-10 3:35 ` Anthony Liguori
0 siblings, 2 replies; 9+ messages in thread
From: Richard W.M. Jones @ 2010-03-09 14:11 UTC (permalink / raw)
To: Sebastian Herbszt; +Cc: kvm-devel, Theodore Ts'o, qemu-devel
On Wed, Nov 18, 2009 at 09:19:53PM +0100, Sebastian Herbszt wrote:
> Theodore Ts'o wrote:
>
> [snip]
>
>> I was ultimately able to work around the solution by deleting the
>> /usr/local/share/qemu/pxe-*.bin files, but that's a bit of a botch. It
>> would be nice if there was a way to disable the gPXE boot option roms;
>> if you know you are booting off of a passed in hard drive image or
>> passed in a kernel for a direct boot, there's no reason why we might
>> want to do a gPXE boot.
>>
>> It would be nice if there was a way to disable option roms automatically
>> if -kernel is specified, or if -boot order doesn't include 'n', or
>> perhaps with an explicit option to suppress all boot option roms (or all
>> networking options).
>>
>> What sort of approach would be considered acceptable? Did I miss
>> some way of making the right thing happen other than deleting the
>> installed pxe-*.bin files?
>
> I would suggest dropping the auto nic option rom loading and extend "-net"
> with a rom option like "-net nic,model=e1000,rom=pxe-e1000.bin".
Did anyone attempt this?
I noticed also with libguestfs that boot times have spiralled out of
control again, and it seems to be down to the SeaBIOS change. SeaBIOS
accounts for _9_ seconds of the boot sequence, up from very small
(fraction of a second) for the old Bochs BIOS[1].
rm -rf /usr/share/gpxe directory reduces the SeaBIOS share of the boot
time down to about 5 seconds, but that's still a huge regression
compared to the old Bochs BIOS.
I'm sure it's waiting for a keypress or something stupid like that.
It'd be nice if the BIOS could be configured in a "just boot, dammit"
mode where it avoids all interaction with keyboards, network cards,
option ROMs etc.
Rich.
[1] Once I'd put a patch into Bochs BIOS to disable a 3 second
keypress wait.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] Re: Need a way disable gPXE boot
2010-03-09 14:11 ` Richard W.M. Jones
@ 2010-03-10 2:03 ` Kevin O'Connor
2010-03-10 9:51 ` Richard W.M. Jones
2010-03-10 3:35 ` Anthony Liguori
1 sibling, 1 reply; 9+ messages in thread
From: Kevin O'Connor @ 2010-03-10 2:03 UTC (permalink / raw)
To: Richard W.M. Jones
Cc: kvm-devel, seabios, Theodore Ts'o, qemu-devel, Sebastian Herbszt
On Tue, Mar 09, 2010 at 02:11:20PM +0000, Richard W.M. Jones wrote:
> I noticed also with libguestfs that boot times have spiralled out of
> control again, and it seems to be down to the SeaBIOS change. SeaBIOS
> accounts for _9_ seconds of the boot sequence, up from very small
> (fraction of a second) for the old Bochs BIOS[1].
I'm surprised - a significant amount of effort has gone into making
SeaBIOS boot quickly. On my machine, the OS starts loading in well
under a second.
I'm not familiar with libguestfs - is that doing something to alter
the hardware emulation?
-Kevin
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] Re: Need a way disable gPXE boot
2010-03-09 14:11 ` Richard W.M. Jones
2010-03-10 2:03 ` Kevin O'Connor
@ 2010-03-10 3:35 ` Anthony Liguori
2010-03-10 10:00 ` Richard W.M. Jones
1 sibling, 1 reply; 9+ messages in thread
From: Anthony Liguori @ 2010-03-10 3:35 UTC (permalink / raw)
To: Richard W.M. Jones
Cc: kvm-devel, Theodore Ts'o, qemu-devel, Sebastian Herbszt
On 03/09/2010 08:11 AM, Richard W.M. Jones wrote:
> Did anyone attempt this?
>
> I noticed also with libguestfs that boot times have spiralled out of
> control again, and it seems to be down to the SeaBIOS change. SeaBIOS
> accounts for _9_ seconds of the boot sequence, up from very small
> (fraction of a second) for the old Bochs BIOS[1].
>
> rm -rf /usr/share/gpxe directory reduces the SeaBIOS share of the boot
> time down to about 5 seconds, but that's still a huge regression
> compared to the old Bochs BIOS.
>
Sounds like you're using a distro and that the distro has improperly
built the GPXE binaries. We don't look for roms in /usr/share/gpxe in
upstream...
For the ROMs we ship, we set BANNER_TIMEOUT=0.
You should file a bug against your distro and try to reproduce with an
upstream build. SeaBIOS takes no time at all with upstream.
Regards,
Anthony Liguori
> I'm sure it's waiting for a keypress or something stupid like that.
> It'd be nice if the BIOS could be configured in a "just boot, dammit"
> mode where it avoids all interaction with keyboards, network cards,
> option ROMs etc.
>
> Rich.
>
> [1] Once I'd put a patch into Bochs BIOS to disable a 3 second
> keypress wait.
>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] Re: Need a way disable gPXE boot
2010-03-10 2:03 ` Kevin O'Connor
@ 2010-03-10 9:51 ` Richard W.M. Jones
0 siblings, 0 replies; 9+ messages in thread
From: Richard W.M. Jones @ 2010-03-10 9:51 UTC (permalink / raw)
To: Kevin O'Connor
Cc: kvm-devel, seabios, Theodore Ts'o, qemu-devel, Sebastian Herbszt
On Tue, Mar 09, 2010 at 09:03:41PM -0500, Kevin O'Connor wrote:
> On Tue, Mar 09, 2010 at 02:11:20PM +0000, Richard W.M. Jones wrote:
> > I noticed also with libguestfs that boot times have spiralled out of
> > control again, and it seems to be down to the SeaBIOS change. SeaBIOS
> > accounts for _9_ seconds of the boot sequence, up from very small
> > (fraction of a second) for the old Bochs BIOS[1].
>
> I'm surprised - a significant amount of effort has gone into making
> SeaBIOS boot quickly. On my machine, the OS starts loading in well
> under a second.
By a process of elimination, last night I worked out that the change
is down to the following option ROMs:
gPXE (not sure which exactly): 5 seconds
pxe-virtio.bin: 4 seconds
I can't find the source for the latter, but it seems neither is part
of SeaBIOS, but are added from other sources by the Fedora build of
qemu.
I built a custom version of SeaBIOS [nicely documented code BTW, once
I'd read the README file it was very simple to understand and
customize!] which booted in under a second.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] Re: Need a way disable gPXE boot
2010-03-10 3:35 ` Anthony Liguori
@ 2010-03-10 10:00 ` Richard W.M. Jones
0 siblings, 0 replies; 9+ messages in thread
From: Richard W.M. Jones @ 2010-03-10 10:00 UTC (permalink / raw)
To: Anthony Liguori
Cc: kvm-devel, Theodore Ts'o, qemu-devel, Sebastian Herbszt
On Tue, Mar 09, 2010 at 09:35:11PM -0600, Anthony Liguori wrote:
> On 03/09/2010 08:11 AM, Richard W.M. Jones wrote:
>> Did anyone attempt this?
>>
>> I noticed also with libguestfs that boot times have spiralled out of
>> control again, and it seems to be down to the SeaBIOS change. SeaBIOS
>> accounts for _9_ seconds of the boot sequence, up from very small
>> (fraction of a second) for the old Bochs BIOS[1].
>>
>> rm -rf /usr/share/gpxe directory reduces the SeaBIOS share of the boot
>> time down to about 5 seconds, but that's still a huge regression
>> compared to the old Bochs BIOS.
>>
>
> Sounds like you're using a distro and that the distro has improperly
> built the GPXE binaries. We don't look for roms in /usr/share/gpxe in
> upstream...
>
> For the ROMs we ship, we set BANNER_TIMEOUT=0.
>
> You should file a bug against your distro and try to reproduce with an
> upstream build. SeaBIOS takes no time at all with upstream.
Yes, you're right, I was totally wrong to be blaming SeaBIOS here,
which is actually a nicely written bit of code. I filed a bug with
Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=572104
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2010-03-10 10:00 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-11-18 18:11 [Qemu-devel] Need a way disable gPXE boot Theodore Ts'o
2009-11-18 19:53 ` Anthony Liguori
2009-11-18 22:37 ` tytso
2009-11-18 20:19 ` [Qemu-devel] " Sebastian Herbszt
2010-03-09 14:11 ` Richard W.M. Jones
2010-03-10 2:03 ` Kevin O'Connor
2010-03-10 9:51 ` Richard W.M. Jones
2010-03-10 3:35 ` Anthony Liguori
2010-03-10 10:00 ` Richard W.M. Jones
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.