Syslinux - Nov 2013 - Sysinux 6 will not boot ISOs on BIOS (i.e. pre-UEFI) systems

On 11/24/2013 09:23 PM, Gerardo Exequiel Pozzi wrote:
> On 11/23/2013 09:35 AM, Carl Duff wrote:
>> -- Re-sent as original may be stuck at awaiting
"authorisation" (originally
>> sent before I joined the mailing list)
>>
>> Hi All,
>>
>> It is impossible to boot Linux-based ISOs that use Syslinux 6.02 via CD
or
>> DVD on older - non-UEFI - systems. Any attempt to do so will result in
the
>> following error message: ISOLINUX 6.02 ETCDisolinux: Disk error 01, AX
>> 4279, drive FE
>>
>> It is still possible to boot / install via USB data-stick, and in a
Virtual
>> Machine. Where using a newer PC with UEFI, even in Legacy mode (and
with
>> the UEFI partition completely removed), ISOs using Syslinux 6.02 will
still
>> go through the UEFI menu.
>>
>> I also noticed that (at least some) OSs not using syslinux 6.02
won't
>> recognise ISOs that do. For example, the file managers of Mint 13,
Windows
>> 7, and Windows 8 all wrongly "see" blank discs).
>>
>> As a consequence, I am aware that the Manjaro Linux team have reverted
to
>> using syslinux 4 for their ISOs.
>>
>> This is certainly not an issue with corrupted downloads, burning, or
dodgy
>> computer disc-drives.
>>
>> Best Wishes,
>> Carl Duff
>> _______________________________________________
>> Syslinux mailing list
>> Submissions to Syslinux at zytor.com
>> Unsubscribe or set options at:
>> http://www.zytor.com/mailman/listinfo/syslinux
>> Please do not send private replies to mailing list traffic.
>>
>>
> 
> Hello guys,
> 
> I am the maintainer of archiso (live-iso creator for Arch Linux).
> 
> Originally, I was not able to reproduce the issue on my machine. But now
> I can do. I made an ISO image that fails to boot.
> 
> The weird thing is: that under the same conditions, trying to
> simplify/reduce the iso, doing some tests (ie, removing isohybrid-mbr,
> eltorito-alt-boot for EFI, etc..) I can not recreate the bad ISO again!
> 
> So I have two ISO images with same contents, same versions, same version
> of program to generate it, but one works and other does not work!.
> 
> Note that the image that does not work on my real hardware works fine
> under qemu and VirtualBox! (both using ISO and real dvd-rw device).
> 
> When trying to boot the bad iso, I can see the isolinux welcome message
> but not complete "ISOLINUX 6.02 ETCD", then reboot inmediatelly.
> 
> 
> Comparing the output of dumpet the only relevant diference is:
> < 2013.11.23 = BAD
>> 2013.11.24 = OK
> 
> $ diff <(dumpet -i archlinux-2013.11.23-dual.iso) <(dumpet -i
> archlinux-2013.11.24-dual.iso)
> 13c13
> <       Load LBA: 136026 (0x0002135a)
> ---
>>       Load LBA: 22792 (0x00005908)
> 25c25
> <       Load LBA: 136154 (0x000213da)
> ---
>>       Load LBA: 23301 (0x00005b05)
> 
> Maybe too high?
> 
> Here is the command that mkarchiso uses for make the iso [#1]
> 
> https://projects.archlinux.org/archiso.git/tree/archiso/mkarchiso#n373
> 
> 
> -------------------------------------------------------------------
> 
> My machine is:
> 
> Motherboard: Asus M2N32-SLI Deluxe (Firmware: 1603)
> CPU: AMD Athlon 64 X2 5200+ [ADA5200IAA6CS]
> RAM: 4 x 1GB OCZ DDR2 800MHz Platinum Rev 2 (4-4-4-15) [OCZ2P800R21G]
> Optical Drive: LG DVD-RW SATA Dual Layer (Fimware IL00) [GH20NS15]
> 
> -------------------------------------------------------------------
> 
> $ dumpet -i archlinux-2013.11.24-dual.iso
> Validation Entry:
>         Header Indicator: 0x01 (Validation Entry)
>         PlatformId: 0x00 (80x86)
>         ID: ""
>         Checksum: 0x55aa
>         Key bytes: 0x55aa
> Boot Catalog Default Entry:
>         Entry is bootable
>         Boot Media emulation type: no emulation
>         Media load segment: 0x0 (0000:7c00)
>         System type: 0 (0x00)
>         Load Sectors: 4 (0x0004)
>         Load LBA: 22792 (0x00005908)
> Section Header Entry:
>         Header Indicator: 0x91 (Final Section Header Entry)
>         PlatformId: 0xef (EFI)
>         Section Entries: 1
>         ID: ""
> Boot Catalog Section Entry:
>         Entry is bootable
>         Boot Media emulation type: no emulation
>         Media load address: 0 (0x0000)
>         System type: 0 (0x00)
>         Load Sectors: 63488 (0xf800)
>         Load LBA: 23301 (0x00005b05)
> 
> $ dumpet -i archlinux-2013.10.03-dual.iso
> Validation Entry:
>         Header Indicator: 0x01 (Validation Entry)
>         PlatformId: 0x00 (80x86)
>         ID: ""
>         Checksum: 0x55aa
>         Key bytes: 0x55aa
> Boot Catalog Default Entry:
>         Entry is bootable
>         Boot Media emulation type: no emulation
>         Media load segment: 0x0 (0000:7c00)
>         System type: 0 (0x00)
>         Load Sectors: 4 (0x0004)
>         Load LBA: 23079 (0x00005a27)
> Section Header Entry:
>         Header Indicator: 0x91 (Final Section Header Entry)
>         PlatformId: 0xef (EFI)
>         Section Entries: 1
>         ID: ""
> Boot Catalog Section Entry:
>         Entry is bootable
>         Boot Media emulation type: no emulation
>         Media load address: 0 (0x0000)
>         System type: 0 (0x00)
>         Load Sectors: 63488 (0xf800)
>         Load LBA: 23185 (0x00005a91)
> 
> 
> 
> 
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
> 
Good I catched!

The problem is the load LBA too high.

How to reproduce (minimal case):

mkdir -p /tmp/test/isolinux
cp /usr/lib/syslinux/bios/isolinux.bin /tmp/test/isolinux
truncate -s 200M /tmp/test/coco
xorriso -as mkisofs \
        -eltorito-boot isolinux/isolinux.bin \
        -eltorito-catalog isolinux/boot.cat \
        -no-emul-boot -boot-load-size 4 -boot-info-table \
        --sort-weight -1 isolinux/isolinux.bin \
        --sort-weight +1 coco \
        -output "/tmp/test.iso" \
        "/tmp/test/"

I added --sort-weight, to force the location of isolinux.bin in a high
LBA address, otherwise in a low addres works fine (just swap +1/-1).

Note that if using isolinux.bin from syslinux-4.07 works fine in both
cases (under high LBA addreses and low).

And yes, again, this only fails on my real hardware, under Qemu and
VirtualBox works fine.





-- 
Gerardo Exequiel Pozzi
\cos^2\alpha + \sin^2\alpha = 1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL:
<http://www.zytor.com/pipermail/syslinux/attachments/20131125/00d8c8d0/attachment.sig>

Hi,

my apologies to Mattias Schlenker for not remembering our
discussion about UEFI of march 2013. It would have been
more relevant in this context than the ia64 problems of
debian-cd of may 2013.


Gerardo Exequiel Pozzi wrote:
> The problem is the load LBA too high.
Nevertheless, this is the first confirmation that BIOS
dislikes high block addresses.
At least the older versions of mkisofs and genisoimage
do not force the boot images to low addresses.
I am curious what a mass test with the users will bring.

As stated earlier, the next version of xorriso will have
sort weight 2 for El Torito boot images by default.
But it will not harm to explicitely use --sort-weight
options with old and new versions of xorriso.

More complicated weight structures may be defined in a
file on disk and read by option --sort-weight-list or
--sort-weight-patterns.

> Note that if using isolinux.bin from syslinux-4.07 works fine in both
> cases (under high LBA addreses and low).
So maybe it is not BIOS but SYSLINUX which does not like
the high addresses. Or both of them in happy cooperation.


Have a nice day :)

Thomas

> As stated earlier, the next version of xorriso will have
> sort weight 2 for El Torito boot images by default.
> But it will not harm to explicitely use --sort-weight
> options with old and new versions of xorriso.
 
FWIW,
 mkisofs is supposed to assign a +2 sort weight by default to the 
eltorito boot image and +1 to the boot catalog, at least when no sort 
file is provided.

I don't know about the sort weight assigned to the boot image by 
mkisofs in case there is a sort file specified that does not 
explicitly include the weight for isolinux.bin.

I also don't know the default weights in mkisofs when there is some 
alternative boot image ("-eltorito-alt-boot" and related options) in 
addition to isolinux.bin.

AFAIK, there is no mkisofs parameter to specify the sort weight of 
one specific file, other than using "-sort <sort_file>", but I
could
be wrong.
 
> 
> More complicated weight structures may be defined in a
> file on disk and read by option --sort-weight-list or
> --sort-weight-patterns.
> 
> 
> > Note that if using isolinux.bin from syslinux-4.07 works fine in both
> > cases (under high LBA addreses and low).
> 
> So maybe it is not BIOS but SYSLINUX which does not like
> the high addresses. Or both of them in happy cooperation.
 
I guess that being isolinux.bin 4.07 smaller than 32KiB (24KiB), 
while isolinux.bin 6.02 being bigger (42KiB), and with the addition 
of multiple alternative boot images in the same ISO, the chances of 
isolinux.bin being located on a higher sector in the media seem to be 
higher.

So, perhaps the potential problem was always there, just that the 
chances of actually triggering it were much lower?

Whichever the case, is there anything that Syslinux can do so to at 
least reduce the chances of triggering this problem? If there isn't, 
is changing the sort weight a solution? Is it the only one? Is it the 
best one? HPA? Anyone?

Regards,
Ady

Thomas wrote:
>
>Nevertheless, this is the first confirmation that BIOS
>dislikes high block addresses.
>At least the older versions of mkisofs and genisoimage
>do not force the boot images to low addresses.
>I am curious what a mass test with the users will bring.
>From experience of making Debian CDs, we've had bug reports years ago
about buggy BIOS implementations that won't boot images using high
LBAs. For ages, we've been simply using two file trees when creating
CDs, putting boot files into the first one mentioned on the
mkisofs/genisoimage command line. Since we started doing that
workaround, things worked much better.

-- 
Steve McIntyre, Cambridge, UK.                                steve at
einval.com
Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/

Hi,

Steve McIntyre wrote:
> For ages, we've been simply using two file trees when creating
> CDs, putting boot files into the first one mentioned on the
> mkisofs/genisoimage command line. Since we started doing that
> workaround, things worked much better.
But this has no effect any more since you began using xorriso.
libisofs does not hand out LBAs in the sequence as the files
were inserted into its image model.

You will have to use --sort-weight et.al. where a low LBA matters.


Have a nice day :)

Thomas

On 11/25/2013 02:59 AM, Steve McIntyre wrote:
> Thomas wrote:
>>
>> Nevertheless, this is the first confirmation that BIOS
>> dislikes high block addresses.
>> At least the older versions of mkisofs and genisoimage
>> do not force the boot images to low addresses.
>> I am curious what a mass test with the users will bring.
> 
> From experience of making Debian CDs, we've had bug reports years ago
> about buggy BIOS implementations that won't boot images using high
> LBAs. For ages, we've been simply using two file trees when creating
> CDs, putting boot files into the first one mentioned on the
> mkisofs/genisoimage command line. Since we started doing that
> workaround, things worked much better.
> 
I suspect it is simply a timeout that triggers due to the longer seek.
Seeking on CD-ROMs is very slow.

	-hpa