Re: Announcing mkisofs 1.13

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

> > I will leech you for the final
> > boot loader of the emerging libburnia OS farm.

> Be my guest.  You can also try grub-devel@gnu.org.

The OS installations tend to overwrite each
others bootloaders. Currently i am working on
the FreeBSD installation which seems to be the
first which did not hide the others. (Ubuntu
and SuSE rather fight over the MBR.)

When the farm is full and i get tired of booting
via rescue discs then i will have to learn how
to manage booting myself.


>   - System area contains GRUB core.img image
>   (GRUB's kernel plus a few modules like filesystem driver).

So one does not have to search for it.

> - core.img is instructed to search in /boot/grub/ for
>   grub.cfg and other modules, etc.

Very convenient.


> So if you'd like to create a GRUB bootable disk, you'd do something
> like:
>   cat boot.img core.img > tmp
>  mkisofs --embedded-boot tmp -o grub.iso -r somedir

I would be interested to learn what mkisofs does
with tmp. Just copy it to the System Area ?
Or is there any info to be inserted that was
gained from the emerging ISO image ?

To what address shall the El Torito record
point ?
(With ISOLINUX we patch the boot image, create
 the El Torito record, and eventually copy a
 patched MBR.)


> > i deem the architecture of separate ISO generator
> > and burn program quite suboptimal.

> You don't like pipes?  What kind of Un*x hacker are you ;-)

Oh, it's not so much the pipe

  mkisofs -M ... -C $c_values ... | cdrecord dev=...

although the libisofs output fifo is better
adapted to the situation than a pipe.

It is rather the method to obtain the parameter
for -C 

  c_values=$(cdrecord dev=... -msinfo 2>/dev/null)

and the way how it is applied blindly to
the device of the burn run. There is a lot of
room for mishaps with this architecture.

Not to forget the fundamental problem, that
mkisofs uses the Linux block device driver for
reading the -M device, whereas the burn programs
use the generic SCSI driver to write.
This is a peculiar mix which makes necessary the
drive tray ballet of growisofs. (Many systems
cannot read via block device what they just
wrote via generic.)

Here i deem the libisoburn architecture superior.
Under its control, libisofs uses libburn for
reading and for writing.
libburn does all its drive operations via the
generic SCSI interface. With our main write
of "growing", reading and writing is guaranteed
to happen on the same media.
(We also have a media-to-media copy method
 "modifying" and the cdrtools method of
 "blind growing" with separates processes for
 reading and writing.)


Have a nice day :)

Thomas