[Debburn-devel] Problem using genisomage

[Thomas Schmitt]

Hi,

> 1. From ISO created under Windows which works OK
>         Nsect 8

So you need indeed -boot-load-size 8 and not 4.


> and this one hangs with message "CDBOOT: Couldn't find BOOTMGR"

Does it get a bit more far than the one with -boot-load-size 4 ?
Possibly you are past El Torito and BIOS problems then.


> As you can see "boot catalog" is in different sector, does it matter?

It should not. The El Torito record at block 17 (decimal) contains
the address of the boot catalog. BIOS should find it there.
Block number 2080 should be no problem.
The block address 2081 of the boot image file is not unusual either.


Having no clue of MS-Windows and etfsboot.com, i can only guess
from ISOLINUX and GRUB2 experience.
ISOLINUX can behave quite the same if option -boot-info-table
is omitted when the ISO is produced. This option patches into the
boot image file its own block address in the ISO image. So it can
at boot time easily find its own content for loading more blocks
from it.

Well, this is specific to ISOLINUX and GRUB2. Probably Microsoft
has chosen different ways if it needs such a hint inside the file.
So option -boot-info-table will probably not help.
(You may try, of course.)


> I want to modify IP in autounattend.xml file.
> I've also tried ISO Master which allows to remove/add files directly
> from/to , but this makes no difference, it keeps hanging (also boot catalog is
> then in different sector).

Ahum. So it repacks the ISO image instead of adding a session ?

The boot catalog address would not be suspicious. But the address
of the boot image file might be of importance (isoinfo "Bootoff" 
tells it in hex and decimal).

You could try my program xorriso for an add-on session.

  # Make a work copy so that the original needs not to be touched
  cp win2012.iso win2012_changed.iso

  # Let xorriso add a session to the work copy
  xorriso -boot_image any keep \
          -dev win2012_changed.iso \
          -map ...where.it.is.on.disk.../autounattend.xml \
               ...where.it.shall.be.in.ISO.../autounattend.xml \
          ...further.manipulation.commands.if.desired... \

The first xorriso command -boot_image "any" "keep" will hopefully
maintain the parameters in the El Torito catalog. (It has never
been tested with a -boot-load-size that is not 4 ...).

Command -dev "win2012_changed.iso" loads the meta data from the
ISO image. Changes will be appended as add-on session.

Command -map schedules a file or directory tree for being copied
into the emerging ISO image.

Finally the end of the command list triggers writing of the
add-on session.

Because the ISO filesystem is in a random-access file, the first
64 kB will be updated. This will also overwrite El Torito boot sector
and catalog. So we have to hope that libisofs is able to properly
copy the original Micorsoft data.

If libisofs fails to do so, i'd like to have a bug report.
(E.g. to bug-xorriso at gnu.org)


In this case there is still a way to force an unaltered set
of Microsoft boot information during the xorriso run:
Put the original Microsoft ISO onto a sequential DVD medium
(DVD-R, DVD+R, unformatted DVD-RW) and keep it appendable:

  xorriso -as cdrecord -v dev=/dev/sr0 -multi win2012.iso

Maybe check whether it boots properly. So that we can blame any
further problems on xorriso's manipulations.

Then manipulate that DVD medium instead of the work copy on
hard disk:

  xorriso -boot_image any keep \
          -dev /dev/sr0 \
          -map ...where.it.is.on.disk.../autounattend.xml \
               ...where.it.shall.be.in.ISO.../autounattend.xml \
          ...further.manipulation.commands.if.desired... \

Because the medium is not overwritable, the first 64 kB will
stay unaltered.
BIOS will probably start from the old El Torito boot sector
(although the specs say it shall be the new one) and thus
find the MS-Windows boot files.
MS-Windows when taking over will hopefully mount the newest
session and thus find your new file content.

The medium will stay appendable. So further manipulations will
be possible, as long as there is still unused space on the DVD.
DVD+R waste less space than DVD-R, when sessions get appended.
If DVD media are too small, then BD-R would be an alternative.

Note that DVD+RW, DVD-RAM, formatted DVD-RW, and BD-RE get their
first 64 kB overwritten as it is done with disk files.


Have a nice day :)

Thomas