[syslinux] isohybrid boot from logical partition

Thomas Schmitt scdbackup at gmx.net
Thu Dec 29 11:16:13 PST 2016


the description of wikipedia matches the behavior of fdisk. Statements
by hpa several years ago indicate that the relative start LBA of logical
partitions is indeed a troublemaker between GRUB and SYSLINUX.


I created by help of fdisk this layout

  Device         Boot Start   End Sectors    Size Id Type
  ebr_fdisk.img1          1    16      16      8K 83 Linux
  ebr_fdisk.img2         17  2047    2031 1015.5K  5 Extended
  ebr_fdisk.img5         64   192     129   64.5K 83 Linux
  ebr_fdisk.img6        200   264      65   32.5K 83 Linux

Indeed the EBRs show relative block start addresses.

At block 17, the EBR of partition 5 has as first partition slot (decimal):

   0   1   2   0 131   3   4   0  47   0   0   0 129   0   0   0

We see at offset 8 the little endian number 47, rather than 64.

At block 199 the EBR of partition 6 has as first partition slot:

   0   3  12   0 131   4  13   0   1   0   0   0  65   0   0   0

At offset 8, there is 1, not 200.


I found an old thread at forums.gentoo.org which leads to a statement
by hpa here on this list:

  "Last I checked, Grub passed an invalid partition offset in DS:SI when
  chainloading a logical partition. Syslinux is partition-table-format
  agnostic, and uses the information passed into it. However, the format
  of DOS partition tables are such that anything that tries to boot a
  logical partition (keep in mind that MS-DOS couldn't boot logical
  partitions at all) has to adjust the partition offset; the stuff that
  comes off the disk is relative to the extended partition that surrounds
  the logical partition, but the chainloaded operating system has no way
  of knowing that."

I.e. SYSLINUX in 2008 expected the forwarded partition entry to be patched
by the chainloader (GRUB) so that its start LBA bears the absolute block
address of the partition start.

Much newer (2014) is
but it refers to quotes of hpa from 2006:

One would have to find out whether GRUB2 meanwhile offers an opportunity
to do this manipulation in "DS:SI" before it chainloads the isohybrid MBR.


Another approach - as mentioned meanwhile by Didier Spaier - would be to
convert the disk partitioning from MBR to GPT.

The task is not too exotic ... Microsoft has docs ... our friendly neighbors
mentions sgdisk with the important warning that you need a few unclaimed
blocks at the end of the disk device.
  "GPT stores a secondary table at the end of disk. [...]"

Before starting this endeavor, one should test by some USB stick whether
the isohybrid --partok MBR is working in GPT partitions. (Code is present
but how much was it tested ?)
Also you'd have to test whether all operating systems on the disk are
able to mount what they need from GPT.

Have a nice day :)


More information about the Syslinux mailing list