I was reading through the El Torito specification a few months ago in
order to debug something and noticed that the excellent mkisofs doesn't
support some very interesting features of it. Neither does any other CD
image mastering program I know of. As a result every x86 OS installation
facility is somewhat crippled. Linux isn't as crippled as NT from this
perspective, but still, booting from CD is nothing like home.
I am referring to the PDF of the hacked-up spec that we all have to use
for CD booting, http://www.nikko.simplenet.com/goldentime/cdrom7.zip. This
could turn into a major marketing feature for Linux as well as relieving
those poor people who have to write 2-stage installation programs.
First some observations on the annoying habits of everyone's install
procedure:
- It's really _really_ unintelligent. You boot off the CD, get several
questions into the install and then it asks you what install media
you want to use, then to insert the correct CD(!) and then chains
to the second-stage install. This has always annoyed me. There are
some good reasons for this behaviour related to the way El Torito
gives you an emulated floppy. Please note that I haven't
written an installation program, in fact the source of nearly every
installation program I've ever seen makes me feel rather ill.
Mandrake and some others are changing that bit by bit, thankyou :-)
- It's very limited because you are cramming everything into 2.88Mb.
This is also a bit silly, you have a great big CD ROM and the best
hardware-detecting OS in existence so why not just allow the data
and code for the installation program to reside on CD and take up
whatever room it wants to?
So what does El Torito let us do?
1. You can have multiple boot images
A quick and simple alternative solution to what most people currently use
that would help a bit is to have an initial CD image on a 2.88 floppy with
little more than the kernel and some kind of mixed human and/or automatic
logic to choose which of an arbitary number of other floppy boot images to
boot as a secondary bootstrap. This might be the quick and dirty option
for getting around current space problems. As far as I can tell you can
chain around between images all day within the spec. I think the SuSE
installer does this to some extent when they offer either an installation
or an emergency boot floppy. But I haven't dived into it to see for sure.
2. You can have no-emulation booting.
This is the really interesting bit. Quote from the PDF in section "5.3 No
Emulation Booting":
--- start quote -------------
When the Media Type is set to zero the BIOS does not use the CD to emulate
a disk. The boot operation loads the requested number of sectors directly
to the specified segment. When loading is complete the BIOS will jump to
segment:0. The associated piece of software can be a "loader" (which
provides its own CD interface), or it can be a stand alone program. The
El Torito specification allows for the loading of FFFF sectors (This would
allow the BIOS to fill the entire low 640k memory area with data). Once
the system jumps to segment:0, the program can retrieve its boot
information by issuing INT 13, Function 4B, AL=01. After the boot process
has been initiated the INT 13 Extensions (functions 41-48) will access the
CD using 800 byte sectors and the LBA address provided to INT 13 is an
absolute sector number. This gives any program running in no emulation
mode the ability to locate the boot catalog, and any other information on
the CD, without providing a device driver.
---- end quote ----------
In other words you can get a CD image to boot from a kernel jump-point.
This isn't like a hard drive bootstrap, this actually loads up to 640k of
data into memory and then sets the IP to an entry point. The kernel can
then work out how to mount /. There would be no commandline parameters so
I would think there would have to be a compile-time option to say "root fs
on CD ROM".
Provided we can get clever with the CD ROM drivers this is exactly what we
need; the net effect would be that the installer developers could treat
the CD exactly like a hard drive, with access to as much data as they
liked. Booting Unix from read-only filesystems was solved years ago.
OK, What Next?
--------------
Someone has to sit down with an ISO image and do some sector editing and
build one of these. Once we know what works and what doesn't then we can
hack mkisofs. I'd probably be tempted to hack mkisofs first, it's fairly
obvious what needs to change.
I don't have any reason to do this apart from hack value. If someone else
does I'm sure they'll get to it long before I've even looked at it. It
might make sense for one of the distributions to fund some experiements.
To head off some obvious suggestions:
* I sent this to eric@andante.jic.com, the author of mkisofs. Bounced.
* There was a thread called "Merging EXT2 and El Torito" on linux-kernel
over a year ago, and it was nothing to do with this.
Regards,
Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/