search for: 1845248

Hi, Duncan Elliot wrote: > As far as I can see, this essentially trims off the first 3 bytes of the > custom isohybrid MBR image before applying it to the ISO. You probably mean this line: memcpy(mbr, &isohdpfx[hd0 + 3 * partok], MBRSIZE); The indize do not apply to bytes but to byte arrays of size MBRSIZE. extern unsigned char isohdpfx[][MBRSIZE]; (hd0 + 3 * partok)

...tes / 512 bytes Disklabel type: dos Disk identifier: 0xfc25117c Device Boot Start End Sectors Size Id Type /dev/sdc1 2048 616447 614400 300M 83 Linux /dev/sdc2 616448 1230847 614400 300M 83 Linux /dev/sdc3 1230848 1845247 614400 300M 83 Linux /dev/sdc4 1845248 7827455 5982208 2.9G 5 Extended /dev/sdc5 1847296 2461695 614400 300M 83 Linux /dev/sdc6 2463744 3078143 614400 300M 83 Linux I 'dd' the ISO to partitions 2, 3, 5 and 6. The ISO will boot successfully (when chainloaded from grub) on 2 and 3, but not on 5 and 6. Thanks,...

...(36+20)(%si), %ebx The start LBA of a GPT partition entry is an 8 byte number stored at offset 32. So obviously the partok version of the MBR tries to read a partition entry. Most probably its own one. If the MBR code from /dev/sdc5 gets to see the partition slot of /dev/sdc4 in /dev/sdc4 1845248 7827455 5982208 2.9G 5 Extended /dev/sdc5 1847296 2461695 614400 300M 83 Linux then a wrong read address for isolinux.bin would be plausible. An assembler programmer could probably make the MBR code show the value of %ecx and compensate the additional bytes by e.g. shortening the error...

Thomas Schmitt wrote: > Since we know that the isolinux.bin binary is well ok on other partitions, > i'd say that the MBR code does not load the right blocks from disk when > it wants to get isolinux.bin. Yes, these are my thoughts as well. I think the jump from GRUB to the isohybrid code on the logical partition is working fine, but when the isohybrid code is trying to jump to