[syslinux] isohybrid boot from logical partition

Thomas Schmitt scdbackup at gmx.net
Thu Dec 29 04:44:45 PST 2016


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



More information about the Syslinux mailing list