Syslinux - Dec 2016 - isohybrid boot from logical partition

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

Hi,

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:

  http://www.syslinux.org/archives/2008-June/010598.html
  "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
  https://sfxpt.wordpress.com/2014/02/17/chainloading-extlinux-from-grub/
but it refers to quotes of hpa from 2006:
  http://www.syslinux.org/archives/2006-October/007590.html

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
too:
  https://wiki.archlinux.org/index.php/Fdisk#Convert_between_MBR_and_GPT
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 :)

Thomas

Thanks for all the input everyone.
I can understand the problem more clearly now.

Didier Spaier wrote:
> Sorry if this is a silly question: why not use a GUID partition
> table instead of using logical partitions?
Not a silly question, I had the same idea and had tried it out but it
didn't work (same error msg).

Ady Ady wrote:
> The typical (modern) "MBR" supports 4 primary bootable
partitions. The
> meaning of "bootable" in that context refers to the possibility
of
> setting the "boot" flag on (one of) them.
I've not found any need to set any boot flags on primary partitions to
get the booting from primary partitions working, so I don't think the
lack of ability to do this on a logical partition is an issue.


@Thomas, thanks for those links.  It seems clear that this issue has
been around for a while and stems from the relative partition offset
that GRUB passes when jumping to a logical partition.
As per your earlier suggestions, I'll look at testing some other
bootloaders.

Taking the point that "Syslinux is partition-table-format agnostic"
I'm guessing that any "fix" that should be made, should be on the
GRUB
side, rather than in the isohybrid side?

Thanks,
Duncan


On 30 December 2016 at 06:16, Thomas Schmitt <scdbackup at gmx.net>
wrote:
> Hi,
>
> 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:
>
>   http://www.syslinux.org/archives/2008-June/010598.html
>   "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
>   https://sfxpt.wordpress.com/2014/02/17/chainloading-extlinux-from-grub/
> but it refers to quotes of hpa from 2006:
>   http://www.syslinux.org/archives/2006-October/007590.html
>
> 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
> too:
>   https://wiki.archlinux.org/index.php/Fdisk#Convert_between_MBR_and_GPT
> 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 :)
>
> Thomas
>