Thomas Schmitt wrote: > 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). > > stage2_eltorito is grub legacy. Please disregard this part > 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. > > 1.96 is way too old. Please disregard. > 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. > > From 1.96 to 1.98 grub-mkrescue was essentially rewritten. Supporting 1.96 (buggy, years old release) is basically a waste of time. Please use either http://alpha.gnu.org/gnu/grub/grub-1.98.tar.gz or bzr checkout from http://bzr.savannah.gnu.org/r/grub/trunk/grub/. > 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. > Feel free to ask. But please use current versions. > When i can perform grub-mkrescue gestures, then > i plan to enable hard-disk emulation so that > others (Vladimir ?) can test that. > > It must be choseable whether to use emulation. By default no emulation should be used (recent BIOSes have problems with emulation). > 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 http://developer.apple.com/legacy/mac/library/documentation/mac/Files/Files-2.html > and make a sketch how a HFS tree would > be structured. > Bad news are that it needs B* trees and isn't compatible with embedded boot trick. B* trees should be relatively easy to generate since we have to do it only once and not maintain their structure over time. > 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. > Just being sorted is mostly enough. Trouble is that HFS uses its own way of sorting. > > >>>> --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 ? > > 63/255 as its what is reported on most harddisks. Most modern tools will ignore this field altogether so putting just anything sane is enough > 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 think they would, especially if they find no FS they expect to (fat). > I would then have to write all zeros except the > one slot in the partition table ? > > Basically you need a fake partition to avoid disk appear as unformatted > ------------------------------------------------ > > 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 ? > > Because sector value is 1-based. > Isn't there any field where the number of sectors > per head, and heads per cylinder is recorded ? > No. In times when it was a hard property of disk it was deemed unnecessary. When big disks appeared C/H/S was largely abandoned. > 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. > /* The head of the start. */ grub_uint8_t start_head;
/* (S | ((C >> 2) & 0xC0)) where S is the sector of the start and C is the cylinder of the start. Note that S is counted from one. */ grub_uint8_t start_sector; /* (C & 0xFF) where C is the cylinder of the start. */ grub_uint8_t start_cylinder; It's pretty much historical. -- 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