From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=59740 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q2kpk-0007FR-SP for qemu-devel@nongnu.org; Thu, 24 Mar 2011 09:44:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q2kph-0005HF-IS for qemu-devel@nongnu.org; Thu, 24 Mar 2011 09:44:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31310) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q2kph-0005Gh-9i for qemu-devel@nongnu.org; Thu, 24 Mar 2011 09:44:13 -0400 Date: Thu, 24 Mar 2011 15:44:02 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] OVMF, SeaBIOS & non-CSM based legacy boot Message-ID: <20110324134402.GC13195@redhat.com> References: <4D87989D.70005@codemonkey.ws> <20110322080048.GQ10151@redhat.com> <20110322200720.GA16147@redhat.com> <20110323123656.GA7766@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michal Suchanek Cc: Jordan Justen , qemu-devel On Thu, Mar 24, 2011 at 01:27:39PM +0100, Michal Suchanek wrote: > On 23 March 2011 23:32, Jordan Justen wrote: > > 2011/3/23 Gleb Natapov : > >> On Tue, Mar 22, 2011 at 02:53:16PM -0700, Jordan Justen wrote: > >>> To support a boot override for UEFI, this full path would be needed. > >>> For the purposes of a UEFI boot override, could the user could provide > >>> the partition & path info? > >>> > >> How the user knows what to provide. In most cases this user will be > >> management anyway. So the use case is like this: new HD is connected > >> to a VM and user wants to boot whatever is installed there. > > > > Yeah, that sounds like something something you or I might do, but not > > your average user. > > > > But, a VM user is most likely not your average user I guess. :) > > > >> With legacy > >> boot this is the matter of running MBR code, with UEFI user need to bo= ot > >> something else and browse file system hierarchy to find magic file to > >> boot from? > >> Sound like step backward even from legacy bios :) > > > > True, it is not a great scenario. > > > > But you can set up the boot options by browsing the filesystems in the > > firmware setup program. > > > >> Is the some notion of default boot in UEFI. > > > > Only for removable media (CD, floppy, USB). =9AIn that case > > /efi/boot/boot(ia32|x64).efi can be 'searched' for. > > >=20 > To the contrary. >=20 > The distinction between removable and fixed media is quite blurry these d= ays. >=20 My thoughts exactly. It is double blurry in virtualization world where moving any media from VM to VM is so easy. > Is an eSATA disk removable? Or a SATA disk connected to AHCI > controller through an internal (but hotplug capable) connector? > And when I unplug the disk, put it into an enclosure and connect > through USB has it magically started to be removable then? >=20 > When installing EFI bootloaders it is suggested to create a small FAT > partition at the start of the disk and put the loader there, just > under this name. >=20 > The Apple EFI also understands some variables stored in their HFS > volumes but that's another story. >=20 > If you want to prepare a disk image for somebody to use you *can* put > the bootloader in the well-known location. >=20 > If you pass just the raw disk image to somebody else it is technically > removable and should use the removable path, and the user can attach > it through the USB emulation if they insist on making it clearly > removable. >=20 > Thanks >=20 > Michal -- Gleb.