/* @(#)README.eltorito 1.2 00/03/18 eric */ What is El Torito? ------------------ Simply put, El Torito is a specification that says how a cdrom should be formatted such that you can directly boot from it. The "El Torito" spec says that ANY cdrom drive should work (scsi/eide) as long as the BIOS supports El Torito. So far this has only been tested with EIDE drives because none of the scsi controllers that has been tested so far appears to support El Torito. The motherboard definately has to support El Torito. The ones that do let you choose booting from HD, Floppy, Network or CDROM. How To Make Bootable CDs ------------------------ For the x86 platform, many BIOS's have begun to support bootable CDs. The standard my patches for mkisofs is based on is called "El Torito". The "El Torito" standard works by making the CD drive appear, through BIOS calls, to be a normal floppy drive. This way you simply put an floppy size image (exactly 1440k for a 1.44 meg floppy) somewhere in the iso fs. In the headers of the iso fs you place a pointer to this image. The BIOS will then grab this image from the CD and for all purposes it acts as if it were booting from the floppy drive. This allows a working LILO boot disk, for example, to simply be used as is. It is simple then to make a bootable CD. First create a file, say "boot.img" which is an exact image of the boot floppu currently in use. There is at least one HOWTO on making bootable floppies. If you have a bootable floppy handy, you can make a boot image with the command dd if=/dev/fd0 of=boot.img bs=10k count=144 assuming the floppy is in the A: drive. Place this image somewhere in the hierarchy which will be the source for the iso9660 filesystem. It is a good idea to put all boot related files in their own directory ("boot/" under the root of the iso9660 fs, for example), but this is not necessary. One caveat - Your boot floppy MUST load any initial ramdisk via LILO, not the kernel ramdisk driver! This is because once the linux kernel starts up, the BIOS emulation of the CD as a floppy disk is circumvented and will fail miserably. LILO will load the initial ramdisk using BIOS disk calls, so the emulation works as designed. The "El Torito" specification requires a "boot catalog" to be created as ll. This is a 2048 byte file which is of no interest except it is required. My patches to mkisofs will cause it to automatically create the boot catalog. You must specify where the boot catalog will go in the iso9660 filesystem. Usually it is a good idea to put it the same place as the boot image, and a name like "boot.catalog" seems appropriate. So we have our boot image in the file "boot.image", and we are going to put it in the directory "boot/" under the root of the iso9660 filesystem. We will have the boot catalog go in the same directory with the name "boot.catalog". The command to create the iso9660 fs in the file bootcd.iso is then mkisofs -b boot/boot.img -c boot/boot.catalog -o bootcd.iso . The -b option specifies the boot image to be used (note the path is relative to the root of the iso9660 disc), and the -c option is for the boot catalog file. Now burn the CD and its ready to boot! CAVEATS ------- I don't think this will work with multisession CDs. If your bootable floppy image needs to access the boot floppy, it has to do so through BIOS calls. This is because if your O/S tries to talk to the floppy directly it will bypass the "floppy emulation" the El Torito spec creates through BIOS. For example, under Linux it is possible to have an initial RAM disk loaded when the kernel starts up. If you let the kernel try to read in the initial RAM disk from floppy, it will fail miserably because Linux is not using BIOS calls to access the floppy drive. Instead of seeing the floppy image on the CD, Linux will be looking at the actually floppy drive. The solution is to have the initial boot loader, called LILO, load your initial RAM disk for you. LILO uses BIOS calls entirely for these operations, so it can grab it from the emulated floppy image. I don't think making a CD bootable renders it unreadable by non-El Torito machines. The El Torito spec uses parts of the iso9660 filesystem which were reserved for future use, so no existing code should care what it does. Mkisofs currently stores identification records in the iso9660 filesystem saying that the system is a x86 system. The El Torito spec also allows one to write PowerPC or Mac id's instead. If you look at the code in write.c you could figure out how to change what is written.