[Top][All Lists]

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

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

From: gary jiang
Subject: Re: [Bug-xorriso] About run xorriso under Win32
Date: Thu, 20 Nov 2014 14:42:27 +0800
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

Hi Thomas,

Thanks for your reply at first!
On 2014/11/19 20:49, Thomas Schmitt wrote:

libisofs: FAILURE : Read error
Sorry for the sparse error message.
In the source code of libisofs this message is triggered by error
code ISO_FILE_READ_ERROR, which is issued at five different

First for your questions (then for diagnosis):

Did I use the wrong cmd [?]
None of the error occasions can be caused by wrong
xorriso -as mkisofs options alone. So there is some problem
with your local system.
I guess so :(, but don't have idea to fix it.
or there is problem with Cygwin compiled xorriso?
Well, i never tested it on Cygwin myself.
This here looks like such an effort:
(Dynamically linked xorriso is a part of libisoburn.)

I have no indications that the binary from that tarball
libisoburn-1.3.8-X-src.tar.xz and command cygport would
be any better than the binary from xorriso-1.3.8.tar.gz.
But if you can locate that Cygwin prepared tarball, then
you may well give it a try.

Thanks for notification, I am trying libisoburn, but I can't find libisoburn-1.3.8-X-src.tar.xz while the download address of libisoburn-1.3.8.tar.gz is listed in the link, so libisoburn-1.3.8.tar.gz is downloaded from website. And the cygwin which I used is really older which version is Cygwin-Easy-2007.03.21.iso, so I can't use it to compile libisoburn1.3.8, also there are some missed tools per the "Runtime requirements". If possible, could you please point me about
how to use the libisoburn? Thanks.
PS: Is there other ways can generate Linux LiveCD (support efi
boot) under Windows?
By hearsay, mkisofs from cdrtools marks a boot image for EFI by
   -eltorito-platform 0xEF -eltorito-boot boot/grub/efi.img
I wrote this into the SYSLINUX isohybrid wiki after a hint
by Ady:
Actually, I had tried mkisofs (schily-cdrtools-3.01a25) with those options as follows:

..\mkisofs.exe -o ..\a.iso -R -J -A "uefiiso" -hide-rr-moved -v -d -N -eltorito-catalog "isolinux/boot.cat" -no-emul-boot -boot-load-size 4 -boot-info-table -eltorito-boot "isolinux/isolinux.bin" -eltorito-alt-boot -eltorito-platform 0xEF -no-emul-boot -b "boot/grub/efi.img" .

However the generated iso can't boot EFI machine due to some reason even it can
boot BIOS machine.

Further, the genisoimage version of Fedora is said to support
option -e. Actually it seems to stem from there. (I adopted
it on hearsay.)

All other options of your xorriso -as mkisofs run should be
usable with mkisofs and genisoimage, too.


Ok, if i did not lose you now to cdrtools or Fedora's cdrkit
(or if they show the same problem) then it would be interesting
to find out what goes wrong.

The error is issued if the file does indeed exist and can be
opened for reading. The read operation itself failed, though.

By checking the five candidates for relevance in your use case,
i could narrow the list to:

    this is used for reading file content from the local filesystem.
    It issues ISO_FILE_READ_ERROR if the operating system call
    read(2) yielded errno EIO.
    That would be a hard disk or network error.

    this is active for boot info table patching. It tries to read
    the whole boot image file from the local filesystem.
    ISOLINUX and GRUB2 need this, and you enabled it by
    This occasion gets its error trigger from above lfs_read()
    and forwards an error code from there.
    Further it returns ISO_FILE_READ_ERROR if not all stat(2)
    announced bytes can be read by one single read(2) command.

So the error must stem from system call read(2) in libisofs
function lfs_read().
Either by being a real errno EIO when reading any of the involved
data files, or by delivering not the full number of file bytes,
when reading file isolinux/isolinux.bin.

If you feel apt to edit a C program, you may distinguish both
occasions by a fprintf() in libisofs/eltorito.c.
In GNU xorriso-1.3.8 (resp. libisofs-1.3.8) this would be in
line 1192:

int iso_patch_eltoritos(Ecma119Image *t)
         ret = iso_stream_read(original, buf, size);
+       fprintf(stderr, "libisofs_DEBUG: size= %ld , ret= %d 0x%X\n",
+               (unsigned long) size, ret, (unsigned int) ret);
         if (ret != (int) size) {
             return (ret < 0) ? ret : (int) ISO_FILE_READ_ERROR;
After added the above line in xorriso-1.3.8\libisofs\eltorito.c, and the following info is printed:

libisofs_DEBUG: size=24576, ret=24541, 0x5FDD
libisofs: FAILURE : Read error
xorriso : FAILURE : Failed to prepare session write run
xorriso : NOTE : -retun_with SORRY 32 triggered by problem severity FAILURE

Do you have some suggestions about it? Thanks.

Best Regards,

This should either put out a line like
   libisofs_DEBUG: size= 2048 , ret= -399442055 0xE830FF79
which would indicate an I/O error from read(2),
or like
   libisofs_DEBUG: size= 2048 , ret= 1999 0x7CF
which would indicate a short read.
If no such message appears, then the problem is with some other
call of lfs_read() and triggered by an I/O error in read(2).

I see that lfs_read() is too naive about the peculiarities
of read(2). In case of a short read(2) it should rather repeat
the read(2) until it gets enough bytes, or EOF, or error.
I will fix this.
If your problem turns out to be short read(2), then i will
ask you to try my fix.

Have a nice day :)


reply via email to

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