Hi, I have an unusual LVM setup where GRUB cannot be installed (see last Threads on LVM) because there is no room for core.img.
The only place where boot data can be put is on a logical volume, but the bootsector (one of diskboot.S or boot.S, I assume) isn't smart enough to understand LVM or filesystems. 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 : 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. 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. I'm not used to assembly programming, but I'll give it a try. Which file contains the bootcode I should edit ? boot.S or diskboot.S ? Any comments ? 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
