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 isolinux.bin, something about the partition structure is causing it to look in the wrong spot. Thomas Schmitt wrote:> What happens if you use a partition editor to delete all MBR partitions > from the ISO image before you put it into the partition on disk ? > (An alternative to using a partition editor is > dd if=/dev/zero conv=notrunc bs=1 count=64 seek=446 of=...iso > )I followed these steps on two of the test ISO's I am using (debian netinst and clonezilla). md5sum confirms the ISO's to be different after the "dd" I then wrote this ISO's to both primary and logical partitions: In both cases the image boots fine off the primary partition, but not the logical (the error message remains the same -> "isolinux.bin missing or corrupt") What is the thought process of clearing the ISO MBR? (it's getting late here, so might not reply to any further replies until tomorrow) Thanks for you help / suggestions so far Duncan On 29 December 2016 at 21:10, Thomas Schmitt <scdbackup at gmx.net> wrote:> Hi, > > do we have bystanders who can read x86 assembler code or know easy-to-grasp > reference docs? > (I left machine code programming when i gave up using my VIC-20.) > > The MBR template isohdppx.bin stems from > http://git.zytor.com/syslinux/syslinux.git/tree/mbr/isohdpfx.S > with macro PARTITION_SUPPORT defined. > > One can see the error message text in there: > > bad_signature: > call error > .ascii "isolinux.bin missing or corrupt.\r\n" > > It seems to be reached only if the seen isolinux.bin does not bear the > magic number of isohybrid capable isolinux.bin. > > cmpl $HYBRID_MAGIC,(isolinux_hybrid_signature) > jne bad_signature > > 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. > > > What happens if you use a partition editor to delete all MBR partitions > from the ISO image before you put it into the partition on disk ? > (An alternative to using a partition editor is > dd if=/dev/zero conv=notrunc bs=1 count=64 seek=446 of=...iso > ) > > > Have a nice day :) > > Thomas >
Hi, Duncan Elliot wrote:> What is the thought process of clearing the ISO MBR?It is not necessary in the partok case, because the partition to which you copy the image encloses the ISO, exposes it for mounting, and protects it from partition editors. (Another idea from assembler riddling turned out to be a red herring.) Without understanding the language or the BIOS habits of MBR booting, i assume that the code inside the #ifdef PARTITION_SUPPORT condition shall get the start block address of the partition from where the MBR was loaded. At offset 8 of an MBR partition slot is stored the 4 byte LBA of the partition start. /* We have non-GPT partition information */ 2: movl 8(%si), %ecx This theory is supported by the numbers in the GPT handling lines /* We have GPT partition information */ movl (32+20)(%si), %ecx movl (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 message. (All together must fit into 432 bytes.) It seems to me that the %si value is expected to be inherited from the run of the previous MBR code, which decided about the partition to be chainloaded. http://wiki.osdev.org/MBR_%28x86%29 "Typical MBR bootstrap code will do the following: [...] * [...] load the Volume Boot Record (VBR, the "bootsector" of the bootloader) from the beginning of the selected partition * set DS:SI pointing to the selected partition table entry * jump to 0x7c00 (with CS set to 0, and DL set to the "drive number") " So the behavior of GRUB might matter and thus testing of other disk MBRs might be of interest. Have a nice day :) Thomas
Hi, i think i found the reason for the boot failure in the definition of Extended Boot Records. https://en.wikipedia.org/wiki/Extended_boot_record#Values "Starting sector = relative offset between this EBR sector and the first sector of the logical partition. Note: This is often the same value for each EBR on the same hard disk; usually 63 for Windows XP or older." So if GRUB hands the partition table entry of /dev/sdc5 over to the isohybrid MBR, then the isohybrid MBR code will see a ridiculously low start address of the partition and thus load the wrong blocks from disk instead of the content of isolinux.bin. The partok isohybrid MBR would have to look up the extended partition in the disk MBR and then hop along the chain of EBRs until it finds itself by some magic number. Currently this looks quite hopeless for 432 bytes of code. One could throw out the noop commands which reserve space for the fake Apple Partition Map block 0 of isohybrid --mac. One could shorten the error message. But i doubt that would suffice. Have a nice day :) Thomas