[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Date: Fri, 02 Apr 2010 00:43:27 +0200
User-agent: Mozilla-Thunderbird (X11/20091109)

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().
> 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 ?
> (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 ?

Vladimir 'φ-coder/phcoder' Serbinenko

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]