From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1OvyKY-00056n-Os for mharc-grub-devel@gnu.org; Wed, 15 Sep 2010 16:11:46 -0400 Received: from [140.186.70.92] (port=47618 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OvyKV-00055U-Mp for grub-devel@gnu.org; Wed, 15 Sep 2010 16:11:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OvyKU-0003Of-6Q for grub-devel@gnu.org; Wed, 15 Sep 2010 16:11:43 -0400 Received: from mail-bw0-f41.google.com ([209.85.214.41]:44507) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OvyKT-0003OW-S0 for grub-devel@gnu.org; Wed, 15 Sep 2010 16:11:42 -0400 Received: by bwz10 with SMTP id 10so1219434bwz.0 for ; Wed, 15 Sep 2010 13:11:40 -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:cc:subject:references:in-reply-to :x-enigmail-version:content-type; bh=OZeIm+X/8auZUCyzMB9F3A4RsLbY4vcPTsRWPZyb95g=; b=NScdYZXgoN1fH2RqcsRCBX1OrDcRRe3TimjBLnZrP1M1pNMbVY81Dl6A5LycDrFwwn 3HfKvfx76/I2GcQIpWIWJwi7TA/hBbbxNKiIESTe8wdbT67Xwcgj3WEE6xpaYXUoxX/n xdRoW1sCuFfOTDhcv8qdlS+YndYc7kBUReXb0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; b=qPotBk91G3W87+lcqcxNgdx0C8q4jKZgwv+hzq1Ik3+9VG9EJW10fUWNPhW+G/2S3L 7AuxDuoYS31DBMdpBjiZoLskpG0ifEzGFnVAkaXaEm8Ax1mBWtaGKIeEqPSqNpOqDxqv sE5FBFU+mYBzXBlTlNf6wcTtXk69njtJSK7vU= Received: by 10.204.68.10 with SMTP id t10mr1684169bki.77.1284581500607; Wed, 15 Sep 2010 13:11:40 -0700 (PDT) Received: from debian.bg45.phnet (252-60.62-81.cust.bluewin.ch [81.62.60.252]) by mx.google.com with ESMTPS id f10sm1704096bkl.5.2010.09.15.13.11.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 15 Sep 2010 13:11:38 -0700 (PDT) Message-ID: <4C912872.5080706@gmail.com> Date: Wed, 15 Sep 2010 22:11:30 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100805 Icedove/3.0.6 MIME-Version: 1.0 To: grub-devel@gnu.org References: <4C116645.8060306@gmail.com> In-Reply-To: <4C116645.8060306@gmail.com> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig6F2C2C7026BA8D44C7781C65" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Cc: Seth Goldberg , =?UTF-8?B?R3LDqWdvaXJlIFN1dHJl?= Subject: Re: [grub-setup] New procedure to choose the embedding area 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: Wed, 15 Sep 2010 20:11:45 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6F2C2C7026BA8D44C7781C65 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/11/2010 12:25 AM, Gr=C3=A9goire Sutre wrote: > Hi, > > [ This is an extended summary of discussions that took place on irc. ] > > The current version of grub-setup requires an msdos or gpt partitioning= > scheme, and is not compatible with hybrid partitioning schemes (i.e. tw= o > top-level disklabels). > > Some disklabels have a specific partition type for bootstrap code, e.g.= > gpt and bsd. Apple partitions have a type that is actually a string (3= 2 > chars), so we could use a specific type for grub bootstrap code (e.g. > `Grub_Bootstrap' or simply `Grub'). Maybe there are other disklabels > (among those supported by GRUB) with a specific partition type for boot= > partitions. > > As you know, there isn't a specific partition type for bootstrap code i= n > msdos disklabels. The current implementation of grub-setup embeds afte= r > the MBR when the detected disklabel is msdos. But this is fragile: > many tools do not hesitate to write in this area regardless of what is > there. > > Ideally, grub-setup should use a dedicated boot partition if it finds > one, and embed after the MBR only as a last resort. Still, we must be > careful with dedicated boot partitions when there are several top-level= > disklabels: the disklabel containing the dedicated boot partition could= > be obsolete (e.g. a leftover from some prior installation). In that > case, we may overwrite user data when embedding in the boot partition. > So we should check that the boot partition does not overlap another > partition. > > To sum up, the new procedure to select the embedding area would be: > > 1. FOREACH top-level partition p /* i.e. p->parent =3D=3D NULL */ > 2. IF p is a dedicated (gpt|bsd|apple|...) boot partition AND > p does not overlap with another top-level partition > 3. THEN > 4. return p > /* No appropriate top-level dedicated boot partition. */ > /* Handle the standard msdos case as an exception. */ > 5. IF the disk contains a single top-level disklabel, and this > disklabel is an msdos one > 6. THEN > 7. return [1, n-1] where n is the minimal start sector of the > top-level partitions > /* Do not try to be too smart... Abort! :-) */ > 8. explain to the user why no embedding area could be found > 9. return NULL > > The first FOREACH loop discards nested partitions, so it would miss for= > instance a dedicated boot partition (hd0,msdos2,bsd7). It would > instead try to embed in the post-MBR gap, which may fail or be more > risky than in the nested dedicated boot partition. > > What do you think regarding this issue? Should we accept any dedicated= > boot partition, even if it is nested? > I've just restructured grub-setup for an easy of new embedding zones. The trouble is to decide whether we have the right to embed into X or Y when we install to Z or T. Currently following rules apply: 1) if installing to hd0 and hd0 is MSDOS-table, you can use MBR gap, if there is no other top-level partition table. 2) if installing to hd0 and hd0 is GPT, you can use BIOS boot partition, if there is no other top-level partition table. New rules will be added in accordance with the governing bodies of relevant partmaps and filesystems or consensus-based if no such body exists. Rules I'd recommend are (based on discussion of ZFS and sunpc cas= e): 3) If /boot is on MyFS, you can use MyFS embedding zone (currently only FAT, Reiser and ZFS have it) if /boot and bootsector are on the same driv= e 4) If /boot is in MyPart you can embed in special partition on MyPart, in this case we need a way to ensure no 2 bootloaders will fight for the same embedding zone > This message is only a proposition, and I look forward to your comments= > and suggestions. > > Gr=C3=A9goire > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig6F2C2C7026BA8D44C7781C65 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/ iF4EAREKAAYFAkyRKHgACgkQNak7dOguQgkUTQD+Kwz7FLEoWtBUofnijdt7kvjL tMC0YEInEZPBjV9fRIoA/3mNH7bAdM/MUlvwL5RRAptaFDVq+hTRLyLU8s1LpYsK =i1SI -----END PGP SIGNATURE----- --------------enig6F2C2C7026BA8D44C7781C65--