[syslinux] MEMDISK El Torito Emulation

[Shao Miller]

Bernd Blaauw wrote:
>
> That's great news! Were there any conditions given to the sharing? I
> guess each person interested in it will have to request permission
> individually? So far the FreeDOS project has had permission from him to
> freely redistribute the binary driver on FreeDOS-related releases.
>
Bart Lagerweij wrote (June 11, 2009):
> Sure no problem. For me this is a very old project.
> I will change it to MIT license.
> Will take a week or so (limited time).
Bernd Blaauw wrote:
>
> I wonder if any
> of the Syslinux bootloaders can handle chained/scripted choices,
> following should load label "fdos" for example
> (using some imagined command "bootmenu" to enter the input which you
> normally give at the Isolinux "boot:" line on screen (and Enter key
> ofcourse). It removes 1 more menu to pass ( I currently solve the issue
> by setting CDrom label "fdos" as default and using 2 second timeout 
> instead)
>
> # this is syslinux.cfg
> :choice1
> label fdmemiso
> kernel memdisk
> append iso initrd=fdbootcd.iso bootmenu=fdos
> # above lines load FreeDOS CD image, then immediately chains into label
> "fdos"
>
It appears that you are suggesting that MEMDISK keep its kernel 
command-line around (it does!) and that some Syslinux variant (ISOLINUX, 
in this instance) in the RAM disk take a look for these arguments.  This 
is an interesting idea, but not currently available.  (That I know of.)  
The trickiest part would be that finding these parameters (the MEMDISK 
command-line) would be the responsibility of the booted items in the RAM 
disk.  Thus all .ISOs in existence would need to be updated in order to 
find and use these parameters.

At this web page[1], a user using "CD Shell" (whose web page is 
referenced in a reply post) uses a CD Shell module to load ISOLINUX.BIN 
and feed it a command as though typed at the "boot:" prompt.  This might 
be interesting to you.  You might be able to determine how CD Shell's 
author accomplishes this.
>
> as fun as that is to reduce its size on a diskette, I ment the binary
> files ISOLINUX.BIN, LDLINUX.SYS and MEMDISK. They make UPX choke, and I
> got no idea why, as UPX can even compress Linux(-kernel) (and for the
> record, FreeDOS kernel as well).
>
Not every executable blob can be compressed in this fashion.  The reason 
being is that whoever loads an executable blob is responsible for 
loading that blob into memory, possibly modifying the blob/reading 
parameters out of the blob/writing parameters into the blob, then 
jumping into a starting point in the blob.

The El Torito specification goes back a little ways now, and does a 
(fairly) simple dance of loading and jumping.  ISOLINUX.BIN is loaded 
and jumped-into.  If it were compressed by UPX, it would have to be a 
very special UPX which understood a lot about boot-time on a PC, would 
need to include decompression code as well as the intelligence to 
shuffle things around in memory so that the uncompressed ISOLINUX.BIN 
would land where it's expecting to land.  I don't believe that UPX 
supports this.

It's possible that MEMDISK could be compressed if UPX supports the Linux 
kernel format which MEMDISK is compliant with.

LDLINUX.SYS would be along the same lines as ISOLINUX.BIN.  It's a 
simple load-and-jump, so UPX would have to decompress, shuffle, then jump.

To tell the truth, I would expect that there would be little gain from 
compressing these components of Syslinux.  If you want some compression, 
you could certainly compress the .ISO or virtual floppy file you are 
booting.  MEMDISK would decompress it.  There is a time versus space 
trade-off.

- Shao Miller

[1] 
http://www.boot-land.net/forums/index.php?s=&showtopic=9787&view=findpost&p=85020