From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N3xpL-00023E-8b for qemu-devel@nongnu.org; Fri, 30 Oct 2009 16:12:03 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N3xpG-00022r-NA for qemu-devel@nongnu.org; Fri, 30 Oct 2009 16:12:02 -0400 Received: from [199.232.76.173] (port=48278 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N3xpG-00022j-GM for qemu-devel@nongnu.org; Fri, 30 Oct 2009 16:11:58 -0400 Received: from e2.ny.us.ibm.com ([32.97.182.142]:35279) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N3xpG-0007xL-8E for qemu-devel@nongnu.org; Fri, 30 Oct 2009 16:11:58 -0400 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by e2.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n9UK4NXH025086 for ; Fri, 30 Oct 2009 16:04:23 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9UKBuKE095108 for ; Fri, 30 Oct 2009 16:11:57 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n9UKBuSx006343 for ; Fri, 30 Oct 2009 16:11:56 -0400 Message-ID: <4AEB488B.4070603@us.ibm.com> Date: Fri, 30 Oct 2009 15:11:55 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4AEB1F84.4010400@siemens.com> <4AEB25B1.8040709@us.ibm.com> <4AEB3F4F.4060407@web.de> <4AEB41A2.1060401@us.ibm.com> <4AEB45F5.4040204@web.de> In-Reply-To: <4AEB45F5.4040204@web.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: Regression due to "Fall back to network boot..." List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel 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