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

[Thomas Schmitt]

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