[Qemu-devel] Regression due to "Fall back to network boot..."

[Qemu-devel] Regression due to "Fall back to network boot..."

[Jan Kiszka]

[ What happened to the scm commit list, btw?]

Hi Anthony,

your patch 94ca5a9859 prevents booting PCs unless some boot order of
less than 4 devices is explicitly specified. The reason is

#define PC_MAX_BOOT_DEVICES 3

and the CMOS-based interface to the BIOS. Maybe the latter can be
enhanced so that the former can be increased, but for now reverting this
commit is probably better.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

[Qemu-devel] Re: Regression due to "Fall back to network boot..."

[Anthony Liguori]

Jan Kiszka wrote:
> [ What happened to the scm commit list, btw?]
>   

I need to move it to qemu.org.

> Hi Anthony,
>
> your patch 94ca5a9859 prevents booting PCs unless some boot order of
> less than 4 devices is explicitly specified. The reason is
>
> #define PC_MAX_BOOT_DEVICES 3
>
> and the CMOS-based interface to the BIOS. Maybe the latter can be
> enhanced so that the former can be increased, but for now reverting this
> commit is probably better.
>   

Sorry about that.  I swore I tested it and it seemed like such a simple 
change.  It's now reverted.

> Jan
>
>   


-- 
Regards,

Anthony Liguori

[Qemu-devel] Re: Regression due to "Fall back to network boot..."

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

Anthony Liguori wrote:
> Jan Kiszka wrote:
>> [ What happened to the scm commit list, btw?]
>>   
> 
> I need to move it to qemu.org.
> 
>> Hi Anthony,
>>
>> your patch 94ca5a9859 prevents booting PCs unless some boot order of
>> less than 4 devices is explicitly specified. The reason is
>>
>> #define PC_MAX_BOOT_DEVICES 3
>>
>> and the CMOS-based interface to the BIOS. Maybe the latter can be
>> enhanced so that the former can be increased, but for now reverting this
>> commit is probably better.
>>   
> 
> Sorry about that.  I swore I tested it and it seemed like such a simple
> change.  It's now reverted.

OK, thanks. Still one complaint: gPXE comes with an annoying boot delay
even if you can boot from disk or have _explicitly_ specified this. I'm
not familiar with it, but I bet there is some magic config switch to
disable this...

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

[Qemu-devel] Re: Regression due to "Fall back to network boot..."

[Anthony Liguori]

Jan Kiszka wrote:
> OK, thanks. Still one complaint: gPXE comes with an annoying boot delay
> even if you can boot from disk or have _explicitly_ specified this. I'm
> not familiar with it, but I bet there is some magic config switch to
> disable this...
>   

Nothing seemed obvious to me.  If anyone has ideas/patches I'm all for it.

> Jan
>   


-- 
Regards,

Anthony Liguori

[Qemu-devel] Re: Regression due to "Fall back to network boot..."

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 587 bytes --]

Anthony Liguori wrote:
> Jan Kiszka wrote:
>> OK, thanks. Still one complaint: gPXE comes with an annoying boot delay
>> even if you can boot from disk or have _explicitly_ specified this. I'm
>> not familiar with it, but I bet there is some magic config switch to
>> disable this...
>>   
> 
> Nothing seemed obvious to me.  If anyone has ideas/patches I'm all for it.

Found it: BANNER_TIMEOUT=0.

It's just blocking the menu, even starting with -S, injecting ctrl-b via
the monitor and then continuing doesn't help. Not sure if we loose much
this way, though.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

[Qemu-devel] Re: Regression due to "Fall back to network boot..."

[Anthony Liguori]

Jan Kiszka wrote:
> Anthony Liguori wrote:
>   
>> Jan Kiszka wrote:
>>     
>>> OK, thanks. Still one complaint: gPXE comes with an annoying boot delay
>>> even if you can boot from disk or have _explicitly_ specified this. I'm
>>> not familiar with it, but I bet there is some magic config switch to
>>> disable this...
>>>   
>>>       
>> Nothing seemed obvious to me.  If anyone has ideas/patches I'm all for it.
>>     
>
> Found it: BANNER_TIMEOUT=0.
>   

But it's not a tunable and I was hoping to not have to pull gpxe into 
the tree and start adding patches.

Maybe we could wait until 0.13 and then introduce the FW cfg interface 
to gpxe?  I've already talked to some of the gpxe devs about it and they 
seem pretty receptive.  That would let us define how long the timeout was.

The advantage of leaving in the timeout is that it lets a user access 
the gPXE menu even if it's not set to be bootable.  You see this on bare 
metal all of the time with gPXE.

> It's just blocking the menu, even starting with -S, injecting ctrl-b via
> the monitor and then continuing doesn't help. Not sure if we loose much
> this way, though.
>   

Regards,

Anthony Liguori

[Qemu-devel] Re: Regression due to "Fall back to network boot..."

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1635 bytes --]

Anthony Liguori wrote:
> Jan Kiszka wrote:
>> Anthony Liguori wrote:
>>  
>>> Jan Kiszka wrote:
>>>    
>>>> OK, thanks. Still one complaint: gPXE comes with an annoying boot delay
>>>> even if you can boot from disk or have _explicitly_ specified this. I'm
>>>> not familiar with it, but I bet there is some magic config switch to
>>>> disable this...
>>>>         
>>> Nothing seemed obvious to me.  If anyone has ideas/patches I'm all
>>> for it.
>>>     
>>
>> Found it: BANNER_TIMEOUT=0.
>>   
> 
> But it's not a tunable and I was hoping to not have to pull gpxe into
> the tree and start adding patches.

It's tunable: Customize -> Console Options -> BANNER_TIMEOUT

> 
> Maybe we could wait until 0.13 and then introduce the FW cfg interface
> to gpxe?  I've already talked to some of the gpxe devs about it and they
> seem pretty receptive.  That would let us define how long the timeout was.
> 
> The advantage of leaving in the timeout is that it lets a user access
> the gPXE menu even if it's not set to be bootable.  You see this on bare
> metal all of the time with gPXE.

Yeah, you see this or even much longer netboot related timeouts these
days everywhere. Specifically when every damn NIC adds its own delay to
the boot, you quickly wait half a minute or more on this stage. Granted,
it's by far not that bad with qemu and gpxe, but this delay is a
regression from the nice speed we just gained a few months ago.

OK, compromise until we have a proper FW interface: BANNER_TIMEOUT=3.
That leaves us with a fair chance to break in but keeps the delay
regression low.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

[Qemu-devel] Re: Regression due to "Fall back to network boot..."

[Anthony Liguori]

Jan Kiszka wrote:
> It's tunable: Customize -> Console Options -> BANNER_TIMEOUT
>   

Ah, I missed that.

>> Maybe we could wait until 0.13 and then introduce the FW cfg interface
>> to gpxe?  I've already talked to some of the gpxe devs about it and they
>> seem pretty receptive.  That would let us define how long the timeout was.
>>
>> The advantage of leaving in the timeout is that it lets a user access
>> the gPXE menu even if it's not set to be bootable.  You see this on bare
>> metal all of the time with gPXE.
>>     
>
> Yeah, you see this or even much longer netboot related timeouts these
> days everywhere. Specifically when every damn NIC adds its own delay to
> the boot, you quickly wait half a minute or more on this stage. Granted,
> it's by far not that bad with qemu and gpxe, but this delay is a
> regression from the nice speed we just gained a few months ago.
>
> OK, compromise until we have a proper FW interface: BANNER_TIMEOUT=3.
> That leaves us with a fair chance to break in but keeps the delay
> regression low
>   

I'm okay with BANNER_TIMEOUT=0 until we get a proper FW interface.

-- 
Regards,

Anthony Liguori

Re: [Qemu-devel] Re: Regression due to "Fall back to network boot..."

[Alexander Graf]

On 30.10.2009, at 21:11, Anthony Liguori wrote:

> Jan Kiszka wrote:
>> Anthony Liguori wrote:
>>
>>> Jan Kiszka wrote:
>>>
>>>> OK, thanks. Still one complaint: gPXE comes with an annoying boot  
>>>> delay
>>>> even if you can boot from disk or have _explicitly_ specified  
>>>> this. I'm
>>>> not familiar with it, but I bet there is some magic config switch  
>>>> to
>>>> disable this...
>>>>
>>> Nothing seemed obvious to me.  If anyone has ideas/patches I'm all  
>>> for it.
>>>
>>
>> Found it: BANNER_TIMEOUT=0.
>>
>
> But it's not a tunable and I was hoping to not have to pull gpxe  
> into the tree and start adding patches.
>
> Maybe we could wait until 0.13 and then introduce the FW cfg  
> interface to gpxe?  I've already talked to some of the gpxe devs  
> about it and they seem pretty receptive.  That would let us define  
> how long the timeout was.
>
> The advantage of leaving in the timeout is that it lets a user  
> access the gPXE menu even if it's not set to be bootable.  You see  
> this on bare metal all of the time with gPXE.

Most users don't want a boot menu when they don't boot from the  
network, right?

So please disable the network boot option rom in the default config!  
That timeout is horrible.


Alex