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
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
