[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-xorriso] About run xorriso under Win32

From: Thomas Schmitt
Subject: Re: [Bug-xorriso] About run xorriso under Win32
Date: Fri, 21 Nov 2014 12:35:43 +0100


since all attempts failed to let libisofs read the announced
amount of bytes from the EL Torito boot image for BIOS, i need
to get an impression what bytes are missing.
My plan is to dump the read data into a file, so that it can
be compared with the original isolinux.bin on disk.

I tested the following change set. Maybe you have to use
a different file path than "/tmp/boot_image_by_xorriso.bin"
which is more appropriate for Cygwin:

--- libisofs/eltorito.c 2014-11-20 12:15:35 +0000
+++ libisofs/eltorito.c 2014-11-21 10:42:10 +0000
@@ -24,6 +24,8 @@
 #include <string.h>
 #include <stdio.h>
+#include <errno.h>
  * This table should be written with the actual values at offset
  * 8 of boot image, when used ISOLINUX boot loader
@@ -1197,6 +1199,18 @@
             if (ret >= 0)
                iso_msg_submit(t->image->id, ISO_FILE_READ_ERROR, 0,
         "Cannot read all bytes from El Torito boot image for boot info table");
+            if (ret >= 0) {
+                FILE *fp = NULL;
+                fp = fopen("/tmp/boot_image_by_xorriso.bin", "wb");
+                if (fp == NULL) {
+                    fprintf(stderr, "libisofs_DEBUG: 
fopen(/tmp/boot_image_by_xorriso.bin) failed with errno= %d\n", errno);
+                } else {
+                    fwrite(buf, ret, 1, fp);
+                    fclose(fp);
+                    fprintf(stderr, "libisofs_DEBUG: Dumped retrieved data to 
+                }
+            }
             return (ret < 0) ? ret : (int) ISO_FILE_READ_ERROR;
Please make above change to xorriso-1.3.9 and redo the failing
xorriso run with -boot-info-table.

The message
  libisofs_DEBUG: Dumped retrieved data to /tmp/boot_image_by_xorriso.bin
is supposed to appear several lines before
  libisofs: FAILURE : Cannot read all bytes from El Torito boot image for boot 
info table
because the latter has to travel through the asynchronous
message queues of libisofs and xorriso.

Then send both files: The original isolinux.bin and the file
which was created during the failed xorriso run.

Further it might be interesting to see what xorriso writes into
an ISO image if it does not fail to patch the boot image.
  xorriso -as mkisofs -o isolinux.iso -no-pad isolinux/isolinux.bin
should produce a very small ISO image isolinux.iso with only
a copy of isolinux.bin in it. This image would be of interest.

Now for the compile time problems:

> 1. libisofs/system_area.h:179: error: conflicting type for 'iso_crc32_gpt'
>     libisofs/libisofs.h:4055: error: previous declaration of 'iso_crc32_gpt' 
> was here

Good catch. Obviously i forgot to delete the declaration
in system_area.h when i moved it to libisofs.h in order to
make it a part of the public API.
Now fixed by:

> 2. libisofs/util.c: In function 'iso_datetime_7':
>     libisofs/util.c:1577: error: wrong type argument to unary minus
> 3. xorriso/misc_funct.c:649: error: invalid operands to binary -

HAVE_TM_GMTOFF is indeed the trigger, but the type of the
global "timezone" variable is the culprit.

I cannot find a Cygwin man page about timezone resp. tzset(3).
My Linux manual prescribes to include <time.h> which is not done
by libisofs/util.h. But xorriso/misc_funct.c does include it.

Do you know about any Cygwin documentation about "timezone" ?

i see

  #ifndef __timezonefunc__
  extern long timezone __asm__ (_SYMSTR (_timezone));

and riddle whether __timezonefunc__ is defined.
If so, then the complained code lines probably try to
negate resp. subtract a function pointer.

> I comment the related lines out just for a workaround.

A better workaround would be to replace timezone by 0.

-    tzoffset = ( - timezone / 60 / 15 ) + 4 * tm.tm_isdst;
+    tzoffset = 4 * tm.tm_isdst;

-     seconds-= timezone - result_tm.tm_isdst * 3600;
+     seconds-= 0 - result_tm.tm_isdst * 3600;

But for automatic handling at ./configure time, i need some
clue about what's going on. Then i can write a test which
sets a macro.

> the iso generated with only efi boot option still can't boot efi
> machine, and seems it has some relationship with the libisofs/util.c since I
> did the following change:
> //tzoffset = ( - timezone / 60 / 15 ) + 4 * tm.tm_isdst;
>     fprintf(stderr, "here is the second compile error\n");
> And the debug info is displayed lots of time when generate iso,

I doubt that faulty time stamps can cause EFI to fail booting.

The EFI firmware is supposed to read the address of the El Torito
boot catalog from the boot record of CD, DVD, or BD. This catalog
contains records about the available boot images. Images for EFI
are recognizable by having platform id code 0xEF.
No time stamps are involved up to this point.

As soon as EFI picked its boot image, the job of the ISO boot
equipment is done. EFI will operate on the FAT filesystem image
which was prepared by GRUB2 and put into the ISO unaltered.

If you boot from USB stick or other hard-disk-like devices then
the position of the FAT image file in the ISO must be marked by
MBR and/or GPT partition. This would be the job of SYSLINUX
program isohybrid --gpt or of the related options of
xorriso -as mkisofs.
  -isohybrid-mbr ...where.installed.by.syslinux.../isohdpfx.bin 
For EFI as addon to option -e (like -no-emul-boot):
Again, no timestamps are involved until the FAT filesystem is
found by EFI.

Have a nice day :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]