Messages in this thread | | | Date | Sun, 29 Aug 1999 08:07:57 +0930 (CST) | From | <> | Subject | Little-known features of El Torito Spec |
| |
Anyone who has sweated to build a 2.88 CD boot image from syslinux and the skinniest fat kernel possible will understand why I'm posting this. There is only a minor impact on the kernel, but overall it could make quite a difference to the way Linux installations are done.
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/
| |