Gerardo Exequiel Pozzi
2013-Nov-25 07:33 UTC
[syslinux] 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>
Thomas Schmitt
2013-Nov-25 09:03 UTC
[syslinux] Sysinux 6 will not boot ISOs on BIOS (i.e. pre-UEFI) systems
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
Ady
2013-Nov-25 10:08 UTC
[syslinux] Sysinux 6 will not boot ISOs on BIOS (i.e. pre-UEFI) systems
> 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
Steve McIntyre
2013-Nov-25 10:59 UTC
[syslinux] Sysinux 6 will not boot ISOs on BIOS (i.e. pre-UEFI) systems
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 agoabout 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/
Thomas Schmitt
2013-Nov-25 18:49 UTC
[syslinux] Sysinux 6 will not boot ISOs on BIOS (i.e. pre-UEFI) systems
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
H. Peter Anvin
2013-Nov-25 21:38 UTC
[syslinux] Sysinux 6 will not boot ISOs on BIOS (i.e. pre-UEFI) systems
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
Possibly Parallel Threads
- Sysinux 6 will not boot ISOs on BIOS (i.e. pre-UEFI) systems
- Sysinux 6 will not boot ISOs on BIOS (i.e. pre-UEFI) systems
- Sysinux 6 will not boot ISOs on BIOS (i.e. pre-UEFI) systems
- Sysinux 6 will not boot ISOs on BIOS (i.e. pre-UEFI) systems
- Sysinux 6 will not boot ISOs on BIOS (i.e. pre-UEFI) systems