Hi, Drake Donahue wrote: > > > mkisofs -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 > > > -boot-info-table -o grub.iso iso > run the script it generates the image, presuming on a linux system
Regrettably i cannot spot stage2_eltorito on my SuSE 10.2 (which has such files but not eltorito) or on Debian 5.04 (where the GRUB installation has files like cdboot.img). The Debian system (where i am novice too) does have /usr/bin/grub-mkrescue which has the line PACKAGE_VERSION=1.96 It uses genisoimage and no --embedded-boot for a MBR-style image. So my plan for development looks like this: - Use grub-mkrescue on Debian to produce a bootable CD. - Examine it and check whether libisofs can produce the same. Make necessary enhancements. - Substitute genisoimage in grub-mkrescue by xorriso and produce bootable CD. - Upgrade Debian to GRUB 1.98 and try to produce an image that boots from USB stick and from CD. This may last a few days. I have to dive into libisofs and check where we might be glued to ISOLINUX, inadvertedly. I will have to learn about GRUB installation and might need to cry for help. When i can perform grub-mkrescue gestures, then i plan to enable hard-disk emulation so that others (Vladimir ?) can test that. Vladimir wrote about HFS: > 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. If you have the time, then try to find specs for HFS and make a sketch how a HFS tree would be structured. I would then prepare hooks in libisofs where a HFS tree can be generated and inserted into the emerging ISO image. Then we could put our knowledge together for the HFS tree generator. libisofs holds a tree model of nodes, from which the image trees get derived. Ideally, i would have made any needed preparations in the tree model, and you would know how to express it in HFS. This is of course a long term open ended endeavor. >>> --protective-msdos-label > 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 What number of sectors/head and heads/cylinder to use ? 32 sectors = 1 head, 64 heads = 1 cylinder would limit C/H/S size to 1 GB, due to the 10 bit limit of cylinder count. The partition table format would allow 63 (or 64 ?) sectors, 255 (or 256 ?) heads = ~ 8 GB. (isohybrid happily truncates C/H/S size to 1 GB and expresses the real size in "LBA end".) me: > > --protective-msdos-label without --embedded-boot ?) Vladimir: > Yes, for example to allow people dd images to USB sticks without a fear > of another OS willing to format the stick. So OSes would pop up dangerous dialogs if they see a USB stick without partition table ? I would then have to write all zeros except the one slot in the partition table ? ------------------------------------------------ Curiosity to fill my lack of MBR knowledge: How does "0x01, 0x00, 0x00, 0x00 (LBA start" match with "0, 2, 0 (C/H/S of the start)" ? I see in isohybrid a similar addition of 1 to start sector. So it is obviously correct. But why ? Isn't there any field where the number of sectors per head, and heads per cylinder is recorded ? Is there a convention to express this in "C/H/S end" ? isohybrid seems to do so: heads-1 , sectors | high(cyls-1) , low(cyls-1) This gives in the sum the number of cyls. One could express that easier. Purpose could be to squeeze in the 1024th cylinder or to express heads/cyl and sectors/head. ------------------------------------------------ Have a nice day :) Thomas _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
