[ Please follow the Reply-To: and head over to debian-cd if you want
to discuss this further... ]

On Fri, Dec 22, 2006 at 03:04:54PM +0000, Steve McIntyre wrote:
>
>Bad news I'm afraid. I've worked through the mkisofs boot code again,
>and I get:
>
>alpha:    Writing alpha boot descriptor at extent 0
>arm:      No boot sector
>amd64:    Writing el torito VD sector at extent 17
>hppa:     Writing hppa boot descriptor at extent 0
>i386:     Writing el torito VD sector at extent 17
>ia64:     Writing el torito VD sector at extent 17
>m68k:     Writing hfs descriptor at extent 0
>mips:     Writing mips boot descriptor at extent 0
>mipsel:   Writing mipsel boot descriptor at extent 0
>powerpc:  Writing hfs descriptor at extent 0
>s390:     No boot sector
>sparc:    Writing sun boot descriptor at extent 0
>          Writing genboot sector at extent 1
>
>I'm looking further to see if it's at all possible to get (e.g.) hppa
>and alpha to live in the same boot sector, but it's really not likely.

Within sector 0:

alpha
=====
bytes 000-<n> : ID string "Linux/Alpha aboot for ISO filesystem.". Looks
like that could be modified if necessary.
480-487 : length of the boot image
488-495 : location of the boot image
504-511 : checksum of the previous bytes in the boot sector
(otherwise blank)

hppa
====
bytes 000-008 : magic header
008-011 : location of kernel image
012-015 : length of kernel image
016-019 : location of ramdisk
020-023 : length of ramdisk
024-150 : boot command line
232-235 : location of kernel image
236-239 : length of kernel image
240-243 : location of boot loader image
244-247 : length of boot loader image
(otherwise blank)

m68k (first 6 sectors)
====
bytes 000-12288 - hfs map (no obvious way to co-exist)

mips
====
jealously scribbles all over the first 512 bytes

mipsel
======
bytes 000-008 : 0-padding
008-011 : magic header
012-015 : boot mode
016-019 : load address
020-023 : exec address
024-027 : boot file length
028-031 : boot file location
(otherwise blank - may contain other boot files, but we don't use it)

powerpc (first 12 sectors)
=======
bytes 000-24576 - hfs map (no obvious way to co-exist)

sparc
=====
bytes 000-127 : ASCII text for disk label (maybe possible to steal
some of the end)
128-267 : data for 8 sparc "partitions"
268-411 : padding
420-511 : "disk" params

So, options as I see it:

m68k, mips and powerpc will not live with anything else.

alpha/hppa:   *may* work, but any display of the ID string on alpha will
look bad due to overloading with the hppa "magic"
bytes. Otherwise no overlap.
alpha/mipsel: *may* work, but any display of the ID string on alpha
will look bad due to overloading with the mipsel
metadata bytes. Otherwise no overlap.
alpha/sparc:  clash, no-go

hppa/mipsel:  clash, no-go
hppa/sparc:   *may* work, but any display of the ID text on sparc will
look bad and depending on the sparc loader the hppa
metadata will confuse things - it will look like a sparc
disk partition

mipsel/sparc: *may* work, but any display of the ID text on sparc will
look bad 

powerpc/m68k both use HFS data and a secondary volume descriptor. In
theory should co-exist with each other(as Apple have done in the
past), but I've no idea whether our stuff will work.

Plus: all of these options will require some gross hacking inside
mkisofs/genisoimage.

amd64/i386/ia64 all do El Torito boot; i386 and amd64 will both use
isolinux and therefore with some debian-cd hacking (already done) the
user can be given a choice of kernels. I know *nothing* about the
details of ia64 to know whether it can be made to co-exist with them
at all.

So, any combination of amd64 and i386 and (one, maybe two) of the
sector 0 arches should work together AFAICS.

If people are *really* interested in trying these out, I can put more
effort in. But as it stands I don't see enough of a chance of success
beyond what I've already done (amd64/i386/ppc) to spend time doing any
more...

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.c
om
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Hafli
ch

[ Post a follow-up to this message ]