ISO MasterThis is the old website, please go to the new website. |
|
EL Torito Specification SupplementAuthor: Andrew SmithDate: 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 ExecuteOne 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:
FilenamesA 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 SeparatorsISO9660 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 namesYet 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 CDsHere is a quote from the mkisofs man page:EL TORITO BOOT INFORMATION TABLE
...
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. CreditsFiguring 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 distributionThis 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. |
Home Screenshots Downloads Documentation News Bugs Credits Help Wanted Translations Postcards Contact |