Common Problems: Difference between revisions

From Syslinux Wiki
Jump to: navigation, search
(Official Binaries)
(Official Binaries)
Line 35: Line 35:
 
==Official Binaries==
 
==Official Binaries==
 
If you've tried using the binaries included in your Linux distribution or compiling by hand but encountered an error, try the official binaries (See [[Download]]).  It's always recommended that you try the latest version but you should at least try the official binaries from the same version if you don't wish to try the latest version.  Often times, newer versions will have already addressed the issue you are experiencing and will also be one of the first recommendations given out if you're not using the current version.
 
If you've tried using the binaries included in your Linux distribution or compiling by hand but encountered an error, try the official binaries (See [[Download]]).  It's always recommended that you try the latest version but you should at least try the official binaries from the same version if you don't wish to try the latest version.  Often times, newer versions will have already addressed the issue you are experiencing and will also be one of the first recommendations given out if you're not using the current version.
 +
 +
If you cannot run the official installer binaries on your system, due to library differences, start by rebuiling ''only'' the installers:
 +
<pre>
 +
make clean
 +
make installer
 +
</pre>
  
 
If you've compiled it by hand and encountered issues, there are several reasons to try the official binaries before thinking you have an issue.
 
If you've compiled it by hand and encountered issues, there are several reasons to try the official binaries before thinking you have an issue.
 
# Your build system: It may be incomplete or be using a version of a package (compiler, etc) that may not interpret the source as well.  NASM before 2.00 can not interpret certain extensions that were added in NASM 2.00 and Syslinux will fail to build from source at this point.
 
# Your build system: It may be incomplete or be using a version of a package (compiler, etc) that may not interpret the source as well.  NASM before 2.00 can not interpret certain extensions that were added in NASM 2.00 and Syslinux will fail to build from source at this point.
 
# Diagnosing: Everyone else will be able to obtain these exact same binaries in order to analyze and diagnose your issue.  Many users and developers always have the latest version on hand and won't need to wait for a download even.  If there is a genuine issue, this aids in diagnosing the issue.
 
# Diagnosing: Everyone else will be able to obtain these exact same binaries in order to analyze and diagnose your issue.  Many users and developers always have the latest version on hand and won't need to wait for a download even.  If there is a genuine issue, this aids in diagnosing the issue.

Revision as of 22:46, 29 June 2010

Watch the name of your kernel

The single most common user error is setting up a kernel configuration which uses one of the reserved extensions:

 none or other Linux kernel image
 .0            PXE bootstrap program (NBP) [PXELINUX only]
 .bin          "CD boot sector" [ISOLINUX only]
 .bs           Boot sector [SYSLINUX only]
 .bss          Boot sector, DOS superblock will be patched in [SYSLINUX only]
 .c32          COM32 image (32-bit COMBOOT)
 .cbt          COMBOOT image (not runnable from DOS)
 .com          COMBOOT image (runnable from DOS)
 .img          Disk image [ISOLINUX only]

Especially the .0 extension bites a lot of people (calling your kernel "redhat-9.0", for example.) Please double-check this carefully.

It is unfortunate that there isn't a standard extension used for Linux kernels, and that none of the commonly loaded data formats (except perhaps COM32) have reliable magic numbers. If you want to name your kernel images something that will avoid confusion, I suggest using the extension .zi (zImage/bzImage).

What's the real name of that file?

When using SYSLINUX or ISOLINUX, make sure that the real name of kernels and other files are the ones you actually specify.

For SYSLINUX, the "real" name is the MS-DOS name, not a VFAT long filename. To verify the real name, you can mount your disk or disk image with, for example:

mount [-r] -t msdos /dev/fd0 /mnt/floppy 
-t msdos will prevent "long names" from showing up. 

Note, in particular, that writing the filesystem with VFAT or UMSDOS enabled will produce very weird names unless they are already entered as valid 8.3 DOS filenames.

For ISOLINUX, the "real" name is the ISO 9660 filename, not a RockRidge or Joliet filename. To verify the real name, mount your CD-ROM or iso image with, for example:

mount -r -t iso9660 -o norock,nojoliet /dev/cdrom /mnt/cdrom 
-t iso9660 -o norock,nojoliet will prevent "long names" from showing up. 

Please note that symbolic links are a RockRidge feature! You will find that if you mount your disk with -o norock that symbolic links show up as short files rather than as links. Therefore, you cannot reference symbolic links; however, hard links should work as expected.

If you are using mkisofs to generate files, there are options which reduce the amount of filename mangling:

mkisofs -allow-leading-dots -allow-multidot -l -relaxed-filenames -no-iso-translate ...

Official Binaries

If you've tried using the binaries included in your Linux distribution or compiling by hand but encountered an error, try the official binaries (See Download). It's always recommended that you try the latest version but you should at least try the official binaries from the same version if you don't wish to try the latest version. Often times, newer versions will have already addressed the issue you are experiencing and will also be one of the first recommendations given out if you're not using the current version.

If you cannot run the official installer binaries on your system, due to library differences, start by rebuiling only the installers:

make clean
make installer

If you've compiled it by hand and encountered issues, there are several reasons to try the official binaries before thinking you have an issue.

  1. Your build system: It may be incomplete or be using a version of a package (compiler, etc) that may not interpret the source as well. NASM before 2.00 can not interpret certain extensions that were added in NASM 2.00 and Syslinux will fail to build from source at this point.
  2. Diagnosing: Everyone else will be able to obtain these exact same binaries in order to analyze and diagnose your issue. Many users and developers always have the latest version on hand and won't need to wait for a download even. If there is a genuine issue, this aids in diagnosing the issue.
Personal tools