From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KKaUj-0007WT-Lp for mharc-grub-devel@gnu.org; Sun, 20 Jul 2008 11:06:41 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KKaUh-0007Vr-Pp for grub-devel@gnu.org; Sun, 20 Jul 2008 11:06:39 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KKaUg-0007V3-6a for grub-devel@gnu.org; Sun, 20 Jul 2008 11:06:39 -0400 Received: from [199.232.76.173] (port=41092 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KKaUg-0007Uy-2I for grub-devel@gnu.org; Sun, 20 Jul 2008 11:06:38 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]:2365) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KKaUf-0007fh-Au for grub-devel@gnu.org; Sun, 20 Jul 2008 11:06:37 -0400 Received: by nf-out-0910.google.com with SMTP id c7so2948572nfi.26 for ; Sun, 20 Jul 2008 08:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:content-type:date:message-id:mime-version:x-mailer; bh=zT4Yhn106pwb6bsPdcYAXyE5TcRskbnRVpH629RQ1kA=; b=enzA6M+UH7qlwkOQBVvYlHVIfG6dyUHR56kv52TQ+yvMjw99RFe3dQ38TL/aTwEaUq FT8ZsL/i1m9CQvxyL0J3qxjzqXCGAu/orvNjJMiMDX61RVGH5kyB1xQAUjN+kjRgXiPQ 3KatIiEVSq4ET6ciNVekFdYdMICgUNFrYcx2Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:content-type:date:message-id :mime-version:x-mailer; b=nTioMPf9WvLN4ExRWTYZgdKumq69coQL3e7xnYbGQrgTStoijR3D86iEXiSZAnPRe7 RoFzEzD0lvTqaE9l0kTPsytk2j4qNJBXFZngx+SL1lwEz1r7WEQ4rtThgFDrcIY9bnRL x3WvIy34luveYNGRErov0rKFWuwM4rvoaY9ys= Received: by 10.210.56.10 with SMTP id e10mr2277674eba.20.1216566395350; Sun, 20 Jul 2008 08:06:35 -0700 (PDT) Received: from ?192.168.1.100? ( [213.37.137.93]) by mx.google.com with ESMTPS id z33sm5820909ikz.0.2008.07.20.08.06.33 (version=SSLv3 cipher=RC4-MD5); Sun, 20 Jul 2008 08:06:34 -0700 (PDT) From: Javier =?ISO-8859-1?Q?Mart=EDn?= To: The development of GRUB 2 In-Reply-To: <1216488291.23098.37.camel@sycorax> References: <1216488291.23098.37.camel@sycorax> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-oGexeQu4cD+Nmfb77G+G" Date: Sun, 20 Jul 2008 17:06:33 +0200 Message-Id: <1216566394.8334.10.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) 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: Sun, 20 Jul 2008 15:06:40 -0000 --=-oGexeQu4cD+Nmfb77G+G Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable El s=C3=A1b, 19-07-2008 a las 19:24 +0200, Jean-Christophe Haessig escribi= =C3=B3: > Hi, Hi there! >=20 > I have an unusual LVM setup where GRUB cannot be installed (see last > Threads on LVM) because there is no room for core.img. 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. PC+GPT schemes might be clumsier, since you'd stamp the main GPT (though the system keeps working with the backup GPT at the end of the disk, as one of my laptops proves). > (...) > 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? At most, you could 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. >=20 > Every 512-byte chunk of core.img contains : > 496 bytes data > 2 bytes magic value > 2 bytes chunk number > 4 bytes random integer > 4 bytes random integer in next chunk > 4 bytes on-disk sector where this chunk is located (serves as hint) >=20 > The boot sector is patched with the random integer found in the first > chunk, and the on-disk sector where it is located. On boot, this disk > sector is loaded and the boot sector code checks if the random integer > matches. > If yes, the disk sector and the expected random integer are updated with > the values found in the newly read block and the program proceeds with > the next block. > If the number doesn't match, the boot code scans the disk from sector 1 > until it finds the sector having the correct random integer, expected > magic value and chunk number. 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. 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?) >=20 > This algorithm should work, regardless from where core.img is stored. It > can even be on a filesystem, as long as file chunks match disk blocks > (which is the case for ext2, I think). Filesystems doing strange things > with files may not work, but usually they aren't used for /boot anyway. 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. --=-oGexeQu4cD+Nmfb77G+G Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQIVAwUASINUeaSl+Fbdeo72AQITnw/9FOgpYIqRTbaEZ0z0AMYupBrXm/08dic9 q5yT19m7rnKsta4TemB9Ejh2zynuV16YmaK4xCK7v5ZNsYyql9M8wSrrw9V2fzua iHAkw9OCnHsUDBhMjUFcRzvObDlE4qUXCO4+d44KVw6lh8I5TeSuoD3m0JNia30+ gL0jIcRqATgQ6grO/XlTpNvYP20VdsCgY/gFZSds1SSHU6M2qQKc72vcZCXnO5uw yJZyLiE25Wsrz2ukPKFBEL8haVxvBG0PpGUPczuup1ya4RR2EzfaidyikzGcnNYn 5cXC9FYx9GWQx9EK9w0Gkm2sxh2CbPAlFygvMkAl9oNYsGnSQnIr0qb1wn2JhCX7 1/D40cGNDWvUKOZSZ+AoiaAr+ydzrNH6qaqEP8sdhT3JZvtXG57DlZIFjL38UAi2 N7phqF18k7sCFrhllFQL8AFRHSXhi3+ahQv9PXfbR+gEA89+rf2uJNE/MdDrRqc1 7wsSV9YtxbbPp5cIi1A+nth4kA749cCyUJMO0cWORdU3M1tO1OYwFlhlblLWKbGp CT4sO9BNHSHsw0N0sdhClYYE1HTKijU9dOeqsdA0DlLuK7nwGa7h59NMDjxDHqzO LlMmOoYxl8M/cRTyr1N51TymlouIgAivPsjJWp1wZTlRhKR5S0lCCCJ5iKGhBWrG rHs2xRyuCJY= =HN0k -----END PGP SIGNATURE----- --=-oGexeQu4cD+Nmfb77G+G--