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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel