From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1OV8IG-0004FH-MR for mharc-grub-devel@gnu.org; Sat, 03 Jul 2010 15:22:28 -0400 Received: from [140.186.70.92] (port=53125 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OV8ID-0004F4-Sg for grub-devel@gnu.org; Sat, 03 Jul 2010 15:22:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OV8IC-00076K-Fl for grub-devel@gnu.org; Sat, 03 Jul 2010 15:22:25 -0400 Received: from mail-bw0-f41.google.com ([209.85.214.41]:60870) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OV8IC-00075x-7h for grub-devel@gnu.org; Sat, 03 Jul 2010 15:22:24 -0400 Received: by bwz9 with SMTP id 9so2680965bwz.0 for ; Sat, 03 Jul 2010 12:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=EW2oOjsglRef/ZmlG7orM3z9NAm1DFZg9EOWzyQxkxk=; b=HUyO1b3LzTBkU8eVOvDr83BAGRP7vH0qZWVeSAaaLw7JrJyvJ1VWW/DP20hJGlZp+z qvdA/pLHTf/opG7TC5A82de5fWVdhaddBHKeDSgtjks0q4dgu3Z7vUo+07MaxZkoP97k BE68yo7h2kgWbFbnPA/gG7stXrtFvANpA0Fiw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; b=lnv/AMpj/YLEmiVTTNIHAKzqAgCr/GKSRpo4ymWA/F9rcV+ctk9FVWTmKhm2pjVgbz GNRNcH6HbEonmthY6fluvi8JSEp6/+ETXILK1HNBqmdfCQ3bLOFSVb0qO87Y87Q7EjKD YvV4DpyKuEQ8tjVBkYxj1N7C9/cHdk1KNT8Yw= Received: by 10.204.76.10 with SMTP id a10mr616759bkk.90.1278184943181; Sat, 03 Jul 2010 12:22:23 -0700 (PDT) Received: from debian.bg45.phnet (gprs37.swisscom-mobile.ch [193.247.250.37]) by mx.google.com with ESMTPS id v6sm9086557bkx.23.2010.07.03.12.22.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 03 Jul 2010 12:22:22 -0700 (PDT) Message-ID: <4C2F8DE2.2080409@gmail.com> Date: Sat, 03 Jul 2010 21:22:10 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100515 Icedove/3.0.4 MIME-Version: 1.0 To: grub-devel@gnu.org References: <63A4C2F2B04E2948B033568534F6C9C578E3D737EE@GVW1095EXB.americas.hpqcorp.net> <4C2CEFAB.8090308@gmail.com> <63A4C2F2B04E2948B033568534F6C9C578E408CA3E@GVW1095EXB.americas.hpqcorp.net> In-Reply-To: <63A4C2F2B04E2948B033568534F6C9C578E408CA3E@GVW1095EXB.americas.hpqcorp.net> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig5F07F208CE93336D80FC5F69" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: grub2 and hybrid MBR booting X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 19:22:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5F07F208CE93336D80FC5F69 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/02/2010 02:13 AM, Elliott, Robert (Server Storage) wrote: >>> In the UEFI Working Group (which defines GPT) and the T13 (ATA) >>> standards bodies, we defined a slightly different method: the GPT=20 >>> partition record now includes a Legacy BIOS Bootable bit that can be = >>> set for a partition like the BIOS boot partition, The algorithm is = >>> documented in T13 EDD-4 revision 2 and later (see >>> http://t13.org/Documents/MinutesDefault.aspx?DocumentType=3D4&Documen= tSta >>> ge=3D1). >>> >>> >>> =20 >> At last. It's refreshing from the usual lie that you need EFI to boot >> from GPT-partitioned disk. >> But I don't see the need to standartise the interface between MBR code= >> and the rest. Standartisation is good only for interoperability betwee= n >> different software. But in this case both parts are from the same >> bootloader so it will only reduce flexibility. >> =20 > The "handoff" contents are defined to better support MBRs and VBRs that= > aren't tightly coupled. =20 Why such schemes are of concern? Someone who wrote the whole bootloader can write 440 bytes more and doesn't need another company for it. If it's for loading one bootloader from another multiboot is much more appropriate. GRUB tries to go away from chainloading as far as possible. It's now still used only for windows but even this will change soon with "ntldr" command which is able to load ntldr or bootmgr file. > The VBR can ignore the data structure if it=20 > doesn't need it. Syslinux felt it helpful to support legacy VBRs > (particularly when they are located < 2.2 TB). > > =20 Unless VBR itself is designed for this you can't load it this way. > > >> When we added GPT support virtually unlimited embedding zone was the >> great plus. Switching to msdos-like scheme would be a huge step >> backwards (especially that you have no MBR gap). It's a repetion of ol= d >> mistakes under new sauce. MSDOS scheme already forced anti-patterns an= d >> any new scheme must be based on saner pattern. >> =20 > What's an "anti-pattern"? > > =20 A design decision to avoid. > The change here would be that the grub MBR code would locate the > grub VBR code (the BIOS Boot Partition) by looking for the Legacy BIOS = > Bootable bit in the GPT partition record, rather than have hardcode > the LBA at some offset in the MBR. > > =20 This scheme already showed its flaws in the past. Multibooting by changing this flag is impratical to say the least and over-reliance on this flag to locate boot partition made it that bootloader must set this flag before chainloading, so no bootloader other than microsoft one implements msdos scheme. You would need a flag per bootloader. It boils back to GUID. Using GUID in GPT to locate the embedded zone would be good but it has nothing to do with this standard. Robert made some work in this direction but never finished (he wrote MBR but not some required changes to diskboot.img) and nobody picked up his work. > Although all legacy BIOS boots will fail if LBA 0 goes bad, this allows= > inclusion of more than one legacy bootable partition on the disk to=20 > tolerate a failure in those LBAs. Bad sectors are pretty rare and overwritten boot partition would need manual clear of bootale flag which requires some environment which would be able to just reinstall bootloader. > It would also tolerate failures of=20 > the GPT region (since there's a backup GPT at the end of the disk > that can be used). > > =20 Whether or not use GPT to locate embed partition would be a separate thread and as I said using GUID would be good but noone ever completed it for GRUB. --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig5F07F208CE93336D80FC5F69 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAkwvjekACgkQNak7dOguQgmuGwD+Liftk+k4BQqf4AOT9XBjuchc E0tr2kItWPqkzqMRTiMA/i54vo++z9u8kKX4FztfzNilgh+eGIOa18FWK/qfGJ7l =oRQk -----END PGP SIGNATURE----- --------------enig5F07F208CE93336D80FC5F69--