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 >
> 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.The boot flag is relevant when the bootstrap code says "look for the boot flag and then jump to that partitions VBR" (or similar). When GRUB (or whichever other boot manager / loader) says "jump to partition 'x'", it is not using the boot flag as condition to select the relevant partition. My main point was not really about the boot flag itself, but rather that the classic MBR code (being used by the isohybrid tool) has space for 4 (primary) partitions, so this code knows nothing about a 5th (or higher) partition. Therefore, perhaps using a special MBR boot code that has space for more than 4 partitions within the 512 bytes constraint might be a potential workaround, considering the self-imposed restrictions of using the particular "isohybrid-in-partitions" method.> > > @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.Syslinux's chain.c32 as potential testing example?> > 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, > DuncanRegards, Ady.> > > _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux
Hi, Duncan Elliot wrote:> Taking the point that "Syslinux is partition-table-format agnostic"I don't agree with hpa here. SYSLINUX expects MBR partition table entries with absolute addresses. Those are exactly the primary partition entries. That's not what i would call agnostic. But i agree with his assessment that it is very cumbersome to find the own partition start if the "DS:SI" protocol hands over a raw partition table entry that describes a logical partition.> I'm guessing that any "fix" that should be made, should be on the GRUB > side, rather than in the isohybrid side?One could ask at help-grub at gnu.org whether there is already a feature to change the forwarded partition table entry from relative LBA to absolute LBA. The necessary information is supposed to be available when GRUB prepares the chainloading. Developement of such a feature would need some initial effort. Besides learning the assembler language one would have to find and understand GRUB's chainloading code and the place where "DS:SI" is prepared. Didier Spaier wrote:> > Sorry if this is a silly question: why not use a GUID partition > > table instead of using logical partitions?Duncan Elliot wrote:> Not a silly question, I had the same idea and had tried it out but it > didn't work (same error msg).This would be a SYSLINUX bug. After all the partok isohybrid MBR does have code for reading the start LBA from a GPT entry. I am wondering about the meaning or reason of "+20" in this assembler line: movl (32+20)(%si), %ecx Why that extra offset 20 on the byte offset 32 which is specified by GPT specs (UEFI 2.4, 5.3.3) ? (Do i get the language wrong ?) It would be interesting to see the complete content of %si as perceived by the isohybrid MBR. (At least up to its byte 59.) (Beginning to read about the language of "gas" i am oscillating between nostalgy and shudders. Three cheers for the C language !) Have a nice day :) Thomas
Hi All, I went down the path of testing SYSLINUX with chain.c32 (instead of GRUB) and have had some good success. Initial tests with various ISO's written to logical partition 5 and 6 have worked! I've only tested with a few ISO's (and only in qemu so far), but early results look promising. I'll update with any other progress. Thanks again for all the help Duncan On 30 December 2016 at 19:34, Thomas Schmitt <scdbackup at gmx.net> wrote:> Hi, > > Duncan Elliot wrote: >> Taking the point that "Syslinux is partition-table-format agnostic" > > I don't agree with hpa here. SYSLINUX expects MBR partition table entries > with absolute addresses. Those are exactly the primary partition entries. > That's not what i would call agnostic. > > But i agree with his assessment that it is very cumbersome to find the > own partition start if the "DS:SI" protocol hands over a raw partition > table entry that describes a logical partition. > > >> I'm guessing that any "fix" that should be made, should be on the GRUB >> side, rather than in the isohybrid side? > > One could ask at help-grub at gnu.org whether there is already a feature to > change the forwarded partition table entry from relative LBA to absolute > LBA. > The necessary information is supposed to be available when GRUB prepares > the chainloading. > > Developement of such a feature would need some initial effort. > Besides learning the assembler language one would have to find and > understand GRUB's chainloading code and the place where "DS:SI" is > prepared. > > > Didier Spaier wrote: >> > Sorry if this is a silly question: why not use a GUID partition >> > table instead of using logical partitions? > > Duncan Elliot wrote: >> Not a silly question, I had the same idea and had tried it out but it >> didn't work (same error msg). > > This would be a SYSLINUX bug. After all the partok isohybrid MBR does have > code for reading the start LBA from a GPT entry. > > I am wondering about the meaning or reason of "+20" in this assembler line: > > movl (32+20)(%si), %ecx > > Why that extra offset 20 on the byte offset 32 which is specified by > GPT specs (UEFI 2.4, 5.3.3) ? (Do i get the language wrong ?) > > It would be interesting to see the complete content of %si as perceived > by the isohybrid MBR. (At least up to its byte 59.) > > (Beginning to read about the language of "gas" i am oscillating between > nostalgy and shudders. Three cheers for the C language !) > > > Have a nice day :) > > Thomas >