[syslinux] isohybrid boot from logical partition

[Duncan Elliot]

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
>