Difference between revisions of "Syslinux 6.02 notes"

From Syslinux Wiki
Jump to: navigation, search
m (Syslinux 6.03 was released.)
m (Add Category:Changelog.)
Line 1: Line 1:
<!-- Adding comments so users can find this page easier. -->
<!-- Adding comments so users can find this page easier. -->

Latest revision as of 14:26, 2 November 2018

Syslinux 6.02 known issues

The following items are some of the known issues (and possible solutions) of the official (upstream) Syslinux 6.02 release.

Corresponding Syslinux 6.02 packages in Linux distros might (or might not) include relevant patches.

All users of Syslinux 6.02 are encouraged to update to Syslinux 6.03 (or newer).

Corrupt BTRFS superblock

This seems to be solved for Syslinux 6.03-pre13.

Using the official (upstream) Syslinux 6.02 on BTRFS volumes corrupts the superblock.

Original report:

Possible workaround (which is _not_ the same as the preferable real solution used for 6.03-pre13):

Chainloading might fail

This has been solved for Syslinux 6.03-pre1.

Relevant patch to solve it:


Problems using pxechn.c32

This has been solved for Syslinux 6.03-pre5 6.03-pre2.

See for example:


Relevant commits that should solve the issue:

  • "pxe: Export the initial stack and PXE(NV) structure, fix pxechn"
    (included in 6.03-pre2)

DOS-based installer fails

This has been solved for Syslinux 6.03-pre2.

Relevant commits:


isolinux Disk error message

Errors similar to:

     ETCDisolinux: Disk error 01, AX=42D2, drive FE

might show up when attempting to boot.

Note: the specific "AX=42??" value varies.

This error message shows up, depending on the particular hardware, and specifically depending on the (buggy) BIOS version.

This error might occur when the LBA value of isolinux.bin is "too high".

In some cases, the system automatically reboots instead of showing this specific error message; it doesn't mean that every inexplicable reboot is related to this specific problem.

The recommended solution is to replace Syslinux 6.02 with Syslinux 6.03-pre1 or newer.

Relevant commit that solves the issue:
"isolinux: Clear upper half of EDX"


A relevant mailing list's (long) thread (among others):

The following alternative procedures are reported to solve the issue in several cases.

  • As mentioned above, update to Syslinux 6.03-pre1 or newer.
  • If available, update the system to a newer BIOS version.
  • If the (isohybrid) image was dd' to a (USB) storage media, use an alternative method, such as (for example):
1_ partitioning and formatting the storage media (losing its prior content); then,
2_ using SYSLINUX (or EXTLINUX) to install the bootloader on the storage media; then,
3_ copying the content of the image to the storage media.
Note: the above 3 steps are just a very generic example; each case might require a different order or additional particular details.
  • While building the ISO image, force the "El Torito" boot image to be located at a relatively-low LBA value.
  • cdrtools' mkisofs by default already forces the "El Torito" boot image to use a relatively-low LBA value (which is what we want). Thus, when using cdrtools' mkisofs, this error is probably not going to show up. Explicitly using the "-sort sort_filename" option should help reduce the chances of boot failure.

The following details about cdrtools' mkisofs are provided here just as general information, since cdrtools' mkisofs should work adequately with its default values.

To change the default weighting in mkisofs, use the
"-sort sort_filename" option.

If the weighting is higher, the file will be located closer to the beginning of the media (which is what we want).

If the weighting is lower, the file will be located closer to the end of the media.

The files will be sorted with the highest weights first, and lowest, last. The default weight is zero, except for the boot images (+2) and for the boot catalog (+1).

If the "-sort" option has not been specified, the boot images are sorted with low priority (+2) to the beginning of the medium, and the boot catalog is sorted with low priority (+1) to the beginning of the medium.

Note: the "-sort" option does not sort the order of the file names that appear in the ISO9660 directory. It sorts the order in which the file data is written to the ISO image.

  • For genisoimage, see the above comments for cdrtools' mkisofs. Explicitly using the "-sort sort_filename" option should help reduce the chances of boot failure.

  • When using xorriso, the address of the boot image can be influenced by
   --sort-weight 2 isolinux/isolinux.bin
   --sort-weight -1 isolinux/isolinux.bin
The former pushes it to a lower address (i.e. what we want); the latter to a higher one.
Since version 1.3.4 of xorriso – released 2013Dec. – the "--sort-weight 2" argument is used by default for "El Torito" boot images. Thus, using version 1.3.4 or newer should work around the problem.

Using the following options when building the image with xorriso:
   --sort-weight 2 isolinux/isolinux.bin
   --sort-weight 1 isolinux/boot.cat
is one possible workaround for this problem.

  • One user commented that disabling AHCI in the BIOS settings could be a possible workaround.
Other users were (reluctant or) not able to overcome this problem by means of this particular workaround. In other words, this potential workaround was not acceptable for certain users.
Since changing this BIOS setting can potentially make some OS less stable (when the OS was originally installed with a different BIOS setting) and/or less efficient, this workaround is probably not the best choice.

Booting kernel failed: Invalid argument

This has been solved for Syslinux 6.03-pre5.


Syslinux 6.xx initially boots, but then it doesn't complete the hand over to the Linux kernel. Syslinux 4.xx successfully boots the same system.

In some cases, something like the following is seen:

Loading kernel... OK
Loading initrd... OK
Booting kernel failed: Invalid argument

Some alternative possible behaviors could be:

  • The system returns back to the "boot:" prompt, or to the Syslinux menu.
  • No error message is seen; the system just hangs there.
  • The screen is "cleaned up", leaving just a non-blinking cursor symbol over the upper-left corner and there is no additional activity.

It should be noted that there are other possible reasons for the aforementioned behaviors, so seeing them does not automatically imply that this particular problem is the cause.

This issue has been seen, among others, on some Toshiba computers. It can be replicated in VMs under VirtualBox 4.1.x and under qemu 0.11.1.

Relevant commits: