From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KKt3J-0006zH-QK for mharc-grub-devel@gnu.org; Mon, 21 Jul 2008 06:55:37 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KKt3H-0006xf-Do for grub-devel@gnu.org; Mon, 21 Jul 2008 06:55:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KKt3F-0006vK-8V for grub-devel@gnu.org; Mon, 21 Jul 2008 06:55:34 -0400 Received: from [199.232.76.173] (port=46880 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KKt3F-0006v3-1w for grub-devel@gnu.org; Mon, 21 Jul 2008 06:55:33 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]:64669) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KKt3E-0003bz-Iq for grub-devel@gnu.org; Mon, 21 Jul 2008 06:55:32 -0400 Received: by ug-out-1314.google.com with SMTP id l31so243281ugc.48 for ; Mon, 21 Jul 2008 03:55:31 -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=xCcBk3qVVBu5WqdVYfPky+F33f8Vy0jwBktJz7XXMUY=; b=YLlBNfkZ9b5P1dkL2kclQ9RpkrvTDATU+nu7J3ZTpVvCmjoexrcu66WXdNb1nHOI3Z UcTCYt/Tsp5OI2lmNLjLpXqoDYrvucwULhzbQ7rkJZFYUpQpQRpn9VCwnLb4ufRftC19 Te8scTA8+hLiAIHzaLTstKi5ozReQBn/NgKQQ= 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=l91OcNxiB31W0A2HnCeKuns2Mw4CBTlble8rFtcQ0PhbGS+wQ0OYOcktpTOJZbomgN F72G6cP0NMknRKRqJKYwWrsE8nloJvQA1qte8ZYXAw/JEBfO1PQD/BoP8CYr3gpW9kGR r96flPTfYPh80BRj1YAO4b5V76vDK32R95cTU= Received: by 10.66.220.17 with SMTP id s17mr1512457ugg.48.1216637730808; Mon, 21 Jul 2008 03:55:30 -0700 (PDT) Received: from ?192.168.1.100? ( [213.37.137.93]) by mx.google.com with ESMTPS id t38sm1866653ugc.83.2008.07.21.03.55.28 (version=SSLv3 cipher=RC4-MD5); Mon, 21 Jul 2008 03:55:29 -0700 (PDT) From: Javier =?ISO-8859-1?Q?Mart=EDn?= To: The development of GRUB 2 In-Reply-To: <1216631588.10092.20.camel@sycorax> References: <1216488291.23098.37.camel@sycorax> <1216566394.8334.10.camel@localhost> <1216631588.10092.20.camel@sycorax> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4rI8wCxsLLNDtVHJOTFO" Date: Mon, 21 Jul 2008 12:55:39 +0200 Message-Id: <1216637739.8334.146.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: Mon, 21 Jul 2008 10:55:35 -0000 --=-4rI8wCxsLLNDtVHJOTFO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable El lun, 21-07-2008 a las 11:13 +0200, Jean-Christophe Haessig escribi=C3=B3= : > Le dimanche 20 juillet 2008 =C3=A0 17:06 +0200, Javier Mart=C3=ADn a =C3= =A9crit : > Hi, >=20 > > This should have been fixed by the transition to LZMA as the compressio= n > > algorithm for PC - core.img should now be under 32K and embeddable in > > the 32256 bytes available before the first MBR partition. >=20 > 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). Well, I can't dissent on that, but then your whole HD, from the first to the last LBA block, is full with data that can move at LVM's whim. > > > However, I can ensure that my /boot logical volume is not too far fro= m > > > the beginning of the disk, and I thought about the following algorith= m : > > 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? >=20 > 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. You can move a LV to a certain PV, but apart from that there is not a point in the LVM "specification" or "documentation" that I've seen that can allow you to move data into _specific_ PEs _and_ keep it there: pvmove does the former but does not guarantee they will still be there in, say, a week: the only way I can think of would be to tie the /boot LV to a PV near the start of the disk, but as you said, then you wouldn't be in this dilemma. > > 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. >=20 > 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. First of all, LVM2 LVs don't have to keep consistency iIrc: its PEs can be (though usually aren't) scattered all over the VG PVs, which means that part of core.img could be in LBA blocks 300-330 but the other fragment might be in blocks 814567-814592. In the worst case, your system might have to read the whole disk _once per block_ in core.img, which is about 50 blocks long. That might be a _big_ hit. If that weren't enough, all your system would have to fit in the already-cramped bootsector image, since you said that there is not a single block in the HD available for embedding. In fact, do you know if LVM leaves space in block #0 (its "superblock") for boot code like GRUB's? If not, you can't even install GRUB, since there is no place to install it to. A suggestion: if you want to keep your no-partitions schema, why don't you boot from a floppy, a CD or a USB pendrive? You would save a lot of headaches... > > 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. >=20 > 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 The same kind of geek* that does not partition his hard drives ;) Besides, I was only using NTFS compression as an example: extN filesystems also have a compression feature (though it's not very used). Any other kind of inline addition/alteration of the data on store by the FS (like the addition of a checksum each 128 bytes or so) or the breakage of the assumption that _our_ blocks are still block-aligned on the filesystem would break your system too. Nevertheless, those assumptions, particularly the latter, usually hold, so your system is already quite robust as things go. Cheers! Habbit * I did the same once, formatting a whole disk reiserfs for a temporary storage addition. I've also partitioned an OLD pc laptop with GPT, so yeah, I kinda like experimenting with partitions --=-4rI8wCxsLLNDtVHJOTFO 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) iQIVAwUASIRrKqSl+Fbdeo72AQJk0g//czjuSX2JrAQ1FmslhpqJx8S3YBQW3lhQ Qs0f06ZfW8GJtIChE7/ODGMpH2KB1aM8Nk133fvn/Ta+25t926z7h7w169hSEPTG iM6Pie1H/U042p8KQXYmNytx07XiIlA63WGu39u3gDMfC8ZC0p3tyYSOghFGmiNl iA3i0AnLfPTbcSk0t9CpAv7pF6VVvJqa3sw1XxnJKB+E6gr1UcWzzsgMRbnbz4cJ I8uqcv79mbbhc5oIgVcfPa09WcBAfVeL7Vcug618kj6PIfoEhey3ml8E06crzw0m V4CdXS/9CQhqnrjSZqLCITw64bd1vcq6Qk9INc5qh4VPlgBxd7AYdxpO688mgS/+ Zl5UqN5NhbvkN30+ntfP9L7fz+Z72+LpTkoxi8+BlYk9nkQihG3qzcSILQnupTb0 1LMViUnO+bMkQBtzW7/MD9o8+tDpqSr8zRajl/n7nupBprZgOMw21d8YXELm5Hwq fLYVBmqgdfPwxnUMdqN9ExWN/4nXykgMCawpJCulWQTO2TPdx+wIhYn1hqnzp/gU xniGhYk9T/VswSe3sSrV/Y9yqQPdE52QfJsR9HqCYfbwxzvYS0HaDpOXGeWWXmPF tnG1EHeSqNIO2Y2dxgA9Vl4+Pfl+dUjkG0TxuPIN/YP0Fi0can01mEIU2S24tfeQ YeBDhxEdiSc= =SqAc -----END PGP SIGNATURE----- --=-4rI8wCxsLLNDtVHJOTFO--