Re: Putting core.img anywhere

[Jean-Christophe Haessig]

Le dimanche 20 juillet 2008 à 17:06 +0200, Javier Martín a é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…

JC

signature.asc
Description: Ceci est une partie de message numériquement signée