From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KKrRJ-0001nc-IG for mharc-grub-devel@gnu.org; Mon, 21 Jul 2008 05:12:17 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KKrRG-0001m1-IM for grub-devel@gnu.org; Mon, 21 Jul 2008 05:12:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KKrRE-0001kj-ME for grub-devel@gnu.org; Mon, 21 Jul 2008 05:12:13 -0400 Received: from [199.232.76.173] (port=60706 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KKrRD-0001kO-Ol for grub-devel@gnu.org; Mon, 21 Jul 2008 05:12:11 -0400 Received: from mx1.apinc.org ([88.191.250.15]:54406 helo=smtp.apinc.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KKrRD-000806-1s for grub-devel@gnu.org; Mon, 21 Jul 2008 05:12:11 -0400 Received: from mei67-1-81-56-34-227.fbx.proxad.net ([81.56.34.227] helo=[192.168.0.19]) by smtp.apinc.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1KKrPe-0000qG-Ss for grub-devel@gnu.org; Mon, 21 Jul 2008 11:10:35 +0200 From: Jean-Christophe Haessig To: The development of GRUB 2 In-Reply-To: <1216566394.8334.10.camel@localhost> References: <1216488291.23098.37.camel@sycorax> <1216566394.8334.10.camel@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-aCxOXnlSOTbxYrhING1P" Date: Mon, 21 Jul 2008 11:13:08 +0200 Message-Id: <1216631588.10092.20.camel@sycorax> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-Scan-Signature: cdb77599d67ee3e38f9df3db0f2170ec X-auth-smtp-user: jean-christophe.haessig@dianosis.org X-abuse-contact: apinc-admins@apinc.org X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) Subject: Re: Putting core.img anywhere X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 09:12:15 -0000 --=-aCxOXnlSOTbxYrhING1P Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le dimanche 20 juillet 2008 =C3=A0 17:06 +0200, Javier Mart=C3=ADn a =C3=A9= crit : Hi, > This should have been fixed by the transition to LZMA as the compression > algorithm for PC - core.img should now be under 32K and embeddable in > the 32256 bytes available before the first MBR partition. As I stated earlier my disks are not DOS-partitioned (e.g. pvcreate /dev/hda). I didn't want to have one useless level of the old DOS partition scheme since LVM already does the job (better). > > However, I can ensure that my /boot logical volume is not too far from > > the beginning of the disk, and I thought about the following algorithm = : > How can you do so? Is there a way to force LVM to put a certain LV > within a particular region of a PV within the VG? Short answer : yes. Longer answer : LVM does not (yet) gratuitously move LVs among PVs, LVs stay where they have been created and when you create a LV on an empty PV, it is normally allocated at the beginning of the disk in continuous extents. And yes, using pvmove you can move data anywhere you like. > split your disk in two partitions, one small and one big; and format > both as LVM PVs, then add them to the same VG. You can then force > the /boot LV within the VG to lie in the small PV, but if you take the > trouble to do this it's quite simpler to just create a non-LVM boot > partition. Yes, and were I in that case, I wouldn't have problems anyway. > Theoretically it would work, but this is heavy duty work we're talking > about - potentially reading the whole disk if a single file has moved > due to, say, a defrag. That's why I included the random-number-chain feature. If the file is accidentally moved, it can still be found by the bootsector. Additionnally, GRUB could display a message about this to the user, telling him that it is in degraded mode and that he should re-run some utility to reindex the file. As for reading the entire disk, an arbitrary upper limit could be put to force the boot sector to fail. > Besides, we could hit one of the several BIOS > disk size limits, so you would have to ensure (as you said above) that > core.img lies within the reasonable limits for your BIOS (8G? 32G? > 128G?) I'm confident that my /boot LV does not exceed the first 200M of the drive. > It would work as long as the filesystem stores 512-byte blocks together. > However, with tail-packing features _might_ pose a problem; and > filesystems that altered the data in any way, like NTFS compression or > some kind of inline checksumming/signing would be a no-go. Sure, but who would use NTFS for their /boot ? Most filesystems should work already, I think, otherwise even LILO couldn't work=E2=80=A6 JC --=-aCxOXnlSOTbxYrhING1P Content-Type: application/pgp-signature; name=signature.asc Content-Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkiEUxkACgkQv04Nz8dVki/gsgCgremXQGYrwj1C4o0d+OmKbLFu I4cAn1Uyu1I1bHV++WLPpD2GSlrXszu6 =wNpM -----END PGP SIGNATURE----- --=-aCxOXnlSOTbxYrhING1P--