[ 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. [EMAIL PROTECTED]
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich
signature.asc
Description: Digital signature
