[Qemu-devel] Need a way disable gPXE boot

[Qemu-devel] Need a way disable gPXE boot

[Theodore Ts'o]

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

Re: [Qemu-devel] Need a way disable gPXE boot

[Anthony Liguori]

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

[Qemu-devel] Re: Need a way disable gPXE boot

[Sebastian Herbszt]

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

Re: [Qemu-devel] Need a way disable gPXE boot

[tytso]

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

Re: [Qemu-devel] Re: Need a way disable gPXE boot

[Richard W.M. Jones]

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/

Re: [Qemu-devel] Re: Need a way disable gPXE boot

[Kevin O'Connor]

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

Re: [Qemu-devel] Re: Need a way disable gPXE boot

[Anthony Liguori]

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.
>
>    

Re: [Qemu-devel] Re: Need a way disable gPXE boot

[Richard W.M. Jones]

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

Re: [Qemu-devel] Re: Need a way disable gPXE boot

[Richard W.M. Jones]

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