Re: How to prepare an ISO 9660 CD for booting via GRUB ?

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3166 bytes --]

Thomas Schmitt wrote:
> Hi,
>
> Vladimir '?-coder/phcoder' Serbinenko wrote:
>   
>> - Is it possible to declare the whole iso for hard-disk emulation for
>> providing emulating image for buggy BIOSes
>>     
>
> libisofs.h describes type ELTORITO_HARD_DISC_EMUL
> with API call iso_image_set_boot_image().
> http://bazaar.launchpad.net/%7Elibburnia-team/libisofs/scdbackup/annotate/head%3A/libisofs/libisofs.h
>
> To my knowledge this is not tested yet.
> xorriso surely has no option to trigger it.
> But that is easily implemented as soon as a
> sincere tester shows up.
>
>
>   
Should be easily testable with qemu. I can do it. The only problem is
whether we should declare both possibilities in el torito because having
2 possible boots in eltorito is likely to trigger even more bugs. I
think it should be an option to grub-mkrescue which emulation to use.
>> - Is it possible to have HFS support in xorriso? It would allow merging
>> PPC grub-mkrescue into generic one.
>>     
>
> Ouch.
>
> In principle it should work like Joliet:
> A complete second directory tree that co-exists
> with the ECMA-119/RockRidge tree. They only
> share data file contents.
> But i have no clue of HFS. Actually i use any
> possible excuse to not start working on UDF.
>
> I can promise to help integrating HFS into
> libisofs if somebody shows up who has the
> necessary HFS knowledge and comprehensive
> testing capabilities.
>
>   
I have an imac g3 I could test it on. The only catch is that I have no
burner at home. But it should be manageable. I never looked deeply into
HFS but I think I can do it.
>   
>>>   --modification-date         Override modification date
>>>       
>> this is needed to know the creation date (which is use as disk
>> identifier in GRUB) before image is complete.
>>     
>
> Should not be a big problem. libisofs will get a
> new API call for that.
> Are there more add-on options which i should
> implement ?
>
>
>   
Other than protective label, not off the top of my head.
>>>   --protective-msdos-label    Patch a protective DOS-style label
>>>       
>> This one adds a simple partition table spanning across whole image of
>> type 0xCD
>>     
>
> To bytes 446 - 509 of the image ?
> Type 0xCD in byte 450 ?
>   
Currently we use first and not last entry. You need to:
1) Zero-fill 446-510
2) Put 0x55, 0xAA into 510-512
3) Put 0x80 (for bootable partition), 0, 2, 0 (C/H/S of the start), 0xcd
(partition type), [3 bytes of C/H/S end], 0x01, 0x00, 0x00, 0x00 (LBA
start in little endian), [LBA end in little endian] at 446-462
> Eventually into the data provided by 
> --embedded-boot ?
>   
Yes
> (Does it make sense without --embedded-boot ?)
>
>   
Yes, for example to allow people dd images to USB sticks without a fear
of another OS willing to format the stick.
> Syslinux isohybrid rounds up the image size
> to full MB. (I understand because it sets
> 64 heads * 32 sectors = 2048 * 512 bytes
> per cylinder)
> Is that necessary with --protective-msdos-label ?
>
>   
No


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]