ISO Master

This is the old website, please go to the new website.

EL Torito Specification Supplement

Author: Andrew Smith
Date: 22 September 2006

"EL Torito Specification Supplement" is perhaps a presumptious name for a document written by a part-time amateur, but this is currently the only resource on the web that elaborates on several implementation details left out of the official spec. I wrote this document hoping that never again will someone have to go through the hell of figuring out how boot records on CDs actually work (took me a year, part time).

This is a highly technical paper that probably won't make sense to you unless you are familiar with the ISO9660 (ECMA119) and El Torito standards.

Read not Execute

One serious ommision in the official Phoenix/IBM spec is the lack of a field in the initial/default entry for the size of the virtual disk (see El Torito figure 3) for no-emulation media types. The sector count field at offset 0x06 is the number of sectors the BIOS will read off the disk on boot, not the size of the boot file. These are 512 (0x200) byte sectors by the way, not the 2048 (0x800) byte sectors on an ISO.

This sector count happens to match the size of the boot record for MS Windows NT/2K/XP bootable CDs, they are always 4 virtual/emulated sectors = 2048 bytes. But the spec does not have this constraint and there are other implementations (at least one, isolinux) which have a virtual disk that's much larger than that. So if you don't know how long a file is, how are you supposed to read it (if, for example, you want to extract the boot record from a CD)? Well, the BIOS does not read the entire boot file, it doesn't need to. The BIOS reads the number of sectors it's asked to read and executes whatever is in those sectors. If the executable code in those sectors has instructions to read more, it does. So arguably the El Torito guys didn't mess up, they were just sloppy, not considering the possibility that one might want to simply read the boot record, not execute it.

I have not found a 'clean' solution to this problem, but I have found a working one. Notice the Load RBA field at offset 0x0C in the initial/default entry? This has the same meaning as location of extent at offset 3 of a file record of ISO9660 (see section 9.1.3). The undocumented trick of creating boot records larger than the El Torito sector count is to have the boot record file referenced not only in the initial/default entry but also in the regular ISO9660 filesystem tree.

So here is the some pseudocode for figuring out the size of a no emulation El Torito boot record:
  1. Read the initial/defaut entry (or section entry, if you wish to support multiple images) and record the Load RBA. This is the logical block number of the first logical block of the boot image file on the ISO9660 filesystem.
  2. As you read the directory records of the ISO9660 tree, compare the logical block number of the directory record with the number recorded in step 1.
  3. If you find the right file in step 2, the size of that file as recorded in the directory descriptor (offset 11) is the size of the boot record file referenced in the El Torito initial/default entry.
  4. If you are finished with the directory tree and did not find the right file, assume that the size of the boot record is precisely the number of virtual/emulated sectors recorded at offset 6 of the El Torito initial/default entry. To convert that to number of bytes multiply by 512.


A no-emulation boot record is not self-contained like a floppy or hard disk emulation boot record, it relies on files on the regular ISO9660 filesystem to do any significant work (in theory it doesn't have to but in practice it always does). Which means the tiny boot record must have a tiny driver for accessing files on ISO9660. Note 'tiny', that means no support for extensions like RockRidge and Joliet.

So it needs access to files on the disk and it gets this access by looking up filenames. Clue: the filenames are hard-coded into the boot record binary. Explanation: the files that the boot record relies on need to have the name that the boot record creators expected, the ISO9660 name (same applies to whatever directories it's in).

So if you are remastering a disk, you cannot remangle the file/directory names used by the boot record. If you do, both a Windows NT CD and an isolinux CD will complain about some file missing (NTLDR, or the kernel name).

File Identifier Separators

ISO9660 section 7.5 says that filenames in a directory record must be followed by ";X", where X is a version number (in practice it's always 1, so ";1"). Unfortunately Microsoft misinterpreted this requirement as optional. So the Microsoft boot record off the NT/2K/XP CDs looks for the file "NTLDR", not "NTLDR;1".

This is to say that if you want to remaster a Windows NT/2K/XP installation disk, you have to create a non-complient filesystem, where filenames do not end with ";1".

Directory names

Yet another ISO9660 requirement that's not always followed is the absense of "." in directory names. ISO9660 doesn't explicitly say you cannot have dots in directory names but it does say directory names may not have extensions, and I'm pretty sure they meant no periods.

Some isolinux CDs (the Slackware installation disk, for example) have the kernel inside directories such as "bare.i". In the section "Filenames" above I explained why the files needed by the boot record (and directories they're in) must have the ISO9660 name required by the creator of the boot record. So for the Slackware CD to boot it must have an ISO9660 directory name "bare.i", which breaks the spec.

Truth be told, no operating system (save DOS, perhaps) cares whether you have dots in directory names or not, so they are safe. But be warned that if you want your implementation to work, you cannot enforce the "no extensions" ISO9660 directory naming rule by remangling the directory names.

Boot Info Tables for isolinux CDs

Here is a quote from the mkisofs man page:
       The  format of this table is as follows; all integers are in sec-
       tion 7.3.1 ("little endian") format.

         Offset    Name           Size      Meaning
          8        bi_pvd         4 bytes   LBA of primary volume descriptor
         12        bi_file        4 bytes   LBA of boot file
         16        bi_length      4 bytes   Boot file length in bytes
         20        bi_csum        4 bytes   32-bit checksum
         24        bi_reserved    40 bytes  Reserved

       The 32-bit checksum is the sum of all the  32-bit  words  in  the
       boot file starting at byte offset 64.  All linear block addresses
       (LBAs) are given in CD sectors (normally 2048 bytes).
This is talking about the 56 bytes at offset 8 of the virtual disk (the boot file, ususally called isolinux.bin). This table is required by isolinux, it will refuse to boot if any of the values in it are wrong.

At offset 8 is the logical block number of the primary volume descriptor, this is always 16 in practice. If you pretend that this file has a directory record (ISO9660 section 9.1) the numbers at offset 12 and 16 are the same as the numbers in ISO9660 9.1.3 and 9.1.4, except the format is different (4 bytes instead of 8).

So mind that when you are making a bootable CD with an isolinux boot image, you have to edit the isolinux boot file by setting the numbers above.


Figuring all this out took me a lot of effort. When I became really desperate, I emailed everyone I could find who might know about the topic. Steffen Winterfeldt helped me out a lot and thanks to him I get to keep what sanity I still have for a while longer. Thank you Steffen.

Copyright and distribution

This document is Copyright Andrew Smith 2006. You are allowed to copy this document. You are allowed to distribute it as long as this copyright message is preserved. In fact I encourage you to distribute it widely.

Help Wanted