Re: Putting core.img anywhere

[Javier Martín]

El sáb, 19-07-2008 a las 19:24 +0200, Jean-Christophe Haessig escribió:
> Hi,
Hi there!
> 
> 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.

> 
> 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)
> 
> 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?)
> 
> 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.

signature.asc
Description: Esta parte del mensaje está firmada digitalmente