99 lines
4.5 KiB
Plaintext
99 lines
4.5 KiB
Plaintext
|
/* @(#)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.
|