User:Scdbackup

Testing my proposal for a new El-Torito article.

After trying to apply smaller changes i decided to propose a re-write of large parts of the text.

---

---

---

El-Torito is a standard for creating bootable optical media like CD-ROMs, DVD, or BD. It is an add-on to the ISO 9660 filesystem.

El-Torito describes different ways of booting from an optical medium. The starting point can either be an emulated floppy drive, an emulated hard disk, or a plain block address in the ISO filesystem.

Oldfashioned ways of boot preparations are described in the articles about bootable CD emulated as a floppy drive and about bootable CD using no emulation (via GRUB legacy).

More modern ways are no-emulation setups as made by GRUB2 script grub-mkrescue or as described by the ISOLINUX wiki of the Syslinux project.

Document Scope

The intention of this document is to explain what you need to know from the El-Torito standard to create a bootable CD with your own boot image. Details about the options for ISO 9660 image production can be found on the Mkisofs page.

El Torito Structure

El Torito booting begins by the Boot Record of the ISO 9660 filesystem at block address 0x11. See also article ISO 9660. This Boot Record points to a Boot Catalog which is stored in one or more blocks inside the ISO 9660 filesystem.

The content of Boot Record and Boot Catalog is created during filesystem production by the ISO 9660 producing software.

The Boot Catalog lists the available boot images which may be prepared for multiple system architectures, called "platforms". These images are marked either as emulated floppies, or as emulated hard disks, or as no-emulation images. In any case they are the first stage in the boot process where custom code from the ISO filesystem can be executed.

While the emulated boot images are to be interpreted by the firmware as is supposed for floppies and hard disks, the no-emulation boot images are on their own.

PC-BIOS reads from the Boot Catalog the number of blocks to load, loads them (usually to segment 07c0) and then executes them as code. As with a normal floppy or hard disk, the DL register contains the BIOS drive number.

EFI interprets the boot image as FAT filesystem and looks up a standardized file path for further processing.

The original El Torito specification mentions platforms "80x86", "PowerPC", and "Mac". Boot setups based on GRUB2 and ISOLINUX use "80x86" for PC-BIOS, and a platform id 0xef for (U)EFI which is not listed in the old specs.

Creating the Structure in the ISO filesystem

The following text assumes that the ISO 9660 producing software is compatible to Mkisofs. E.g. mkisofs, genisoimage, or xorrisofs.

Mkisofs expects that the boot images are submitted as data files like any other file in the emerging ISO 9660 filesystem. Normally they are part of the directory trees which get copied into the filesystem.

In most cases the Boot Catalog is represented in the filesystem as data file, too. Its content is nevertheless composed by Mkisofs.

The boot images of ISOLINUX and GRUB2 expect to contain some information about the ISO filesystem and their own location and length. This information is called Boot Info Table and gets inserted by Mkisofs, if desired. Boot Info Table is not specified by El Torito, but is rather a convention introduced by boot loader developers.

Example of ISO Filesystem Production Run For BIOS

Put all necessary directories and files underneath directory ./prepared_for_iso . It will be copied as root directory of the ISO filesystem. Especially make the boot image for PC-BIOS available at path ./prepared_for_iso/boot/loader.sys , so that it will appear in the ISO filesystem as /boot/loader.sys .

Choose an ISO 9660 producing program and eventually its mkisofs emulation command:

prog="mkisofs"

or

prog="genisoimage"

or

prog="xorriso -as mkisofs"

Produce ISO 9660 filesystem image ./bootable.iso

$prog -R -J -c boot/bootcat \
      -b boot/loader.sys -no-emul-boot -boot-load-size 4 \
      -o ./bootable.iso ./prepared_for_iso

-c boot/bootcat - Makes the Boot Catalog accessible as data file.

-b boot/loader.sys -no-emul-boot - Causes /boot/loader.sys to be listed in the emerging Boot Catalog as no-emulation boot image for PC-BIOS.

-boot-load-size 4 - Specifies the number of 512-bytes sectors to load. Four 512-byte sectors (2048 bytes) is one CD sector and is the number supported by most BIOS.

If your boot image needs updating of a Boot Info Table, then add option -boot-info-table after -boot-load-size 4.

After this production run, the emerged data file ./bootable.iso can be burned onto optical media.

Hybrid Setup for BIOS and EFI from CD/DVD and USB stick

The EL Torito Boot Catalog can offer in the same ISO filesystem alternative boot images for PC-BIOS and for EFI.

But El Torito is interpreted by the firmware only if presented on an optical medium: CD, DVD, BD. For booting PC-BIOS or EFI from USB stick or other hard-disk-like devices, there is need for an MBR and a GPT. Both can be stored in the System Area of the ISO 9660 filesystem. Combining them is a matter of slightly tweaking the GPT specs.

The GPT just has to point to the FAT filesystem image that is also pointed to by the EFI entry in the El Torito Boot Catalog.

The MBR should mark in its partition table the range of the ISO image. It might be helpful or not, to also mark the FAT image for EFI in the partition table of the MBR. The MBR of SYSLINUX can be adjusted to jump with its execution onto the El Torito boot image of ISOLINUX. This is known as "isohybrid".

Debian used for its installation image debian-7.1.0-amd64-netinst.iso the following options of xorriso's mkisofs emulation:

xorriso -as mkisofs \
  ... \
  -c isolinux/boot.cat \
  -b isolinux/isolinux.bin \
  -no-emul-boot -boot-load-size 4 -boot-info-table \
  -isohybrid-mbr ./syslinux/usr/lib/syslinux/isohdpfx.bin \
  -eltorito-alt-boot \
  -e boot/grub/efi.img \
  -no-emul-boot -isohybrid-gpt-basdat \
  ... \
  ./boot1 \
  ...

Option -eltorito-alt-boot separates the settings for the BIOS boot image (-b) from those for the EFI boot image (-e).

The files isolinux/isolinux.bin and boot/grub/efi.img get into the ISO image from source directory ./boot1.

File ./syslinux/usr/lib/syslinux/isohdpfx.bin is copied directly from the SYSLINUX installation into the System Area of the ISO image. It contains the isohybrid MBR template. Option -isohybrid-gpt-basdat announces the FAT image boot/grub/efi.img as GPT partition.

See man 1 xorrisofs for details about the options which are in part not supported by mkisofs from cdrtools.

A BareBones Boot Image with Boot Information Table

A Boot Information Table may be put into a boot image. It starts at offset 8 and is 56 bytes long. If you are familiar with Bios Parameter Blocks, you can think of the Boot Information Table as doing a similar job.

[ORG 0x7C00]
[BITS 16]
start:
  jmp   0x0000:boot
  times 8-($-$$) db 0

  ;     Boot Information Table
  bi_PrimaryVolumeDescriptor  resd  1    ; LBA of the Primary Volume Descriptor
  bi_BootFileLocation         resd  1    ; LBA of the Boot File
  bi_BootFileLength           resd  1    ; Length of the boot file in bytes
  bi_Checksum                 resd  1    ; 32 bit checksum
  bi_Reserved                 resb  40   ; Reserved 'for future standardization'

boot:
  ;     Boot code here - set segment registers etc...
  jmp $

If you are already familiar with boot sectors for other media, this should look quite familiar already. As usual, the first thing that the code does is jump to a known segment:offset location, where it will presumably set data and stack segment registers. I have used the times macro to provide padding for the table. This has two distinct advantages: firstly, if you decide to add anything else before the table, it will continue to reside at offset 8. Secondly, if you place more than 8 bytes worth of code before the table, you will get an assembler error. The Boot Information Table may need some explanation:

bi_PrimaryVolumeDescriptor contains the LBA address of the Primary Volume Descriptor, which contains information such as the address and length of the root directory. In practice, this value will normally be 0x10. And yes - no more CHS calculations, for El-Torito no emulation mode on a modern PC, it's normally a safe bet that int 0x13 extensions are available!

bi_BootFileLocation is another LBA address containing the location of the boot image on the CD. The size of the boot image can be found (in bytes) in the bi_BootFileLength field.

bi_Checksum is a 32 bit checksum of all the 32-bit values in the boot file, starting at offset 64 (just after the boot information table).

Important note!

There are some BIOS bugs that might prevent No Emulation booting from working properly on certain machines. A brief list of them is available here

What Next?

The rest of the CD boot process relies on ISO 9660 rather than the El-Torito standards. After you have done the 'normal' boot sector jobs, such as setting segment registers to known values and saving the contents of DL (which contains the BIOS boot drive number), you can start reading the file system, in the 2k that you have available in your boot sector.

Generally, you will want to provide a minimal ISO 9660 driver, so that you can at least find and load your next stage loader. You have an option here - you can either use the path tables to find a file, or perform a full directory walk.