bug-xorriso
[Top][All Lists]
Advanced

[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: Wed, 19 Nov 2014 13:49:13 +0100

Hi,

> 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
occasions.

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.

> or there is problem with Cygwin compiled xorriso?

Well, i never tested it on Cygwin myself.
This here looks like such an effort:
  https://github.com/fd00/yacp/tree/master/libisoburn
(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.


> 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:
  http://www.syslinux.org/archives/2014-June/022334.html

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.

-------------------------------------------------------------
Diagnosis:

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:

libisofs/fs_local.c:lfs_read()
   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. 

libisofs/eltorito.c:iso_patch_eltoritos()
   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
   -boot-info-table.
   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);
+
        iso_stream_close(original);
        if (ret != (int) size) {
            return (ret < 0) ? ret : (int) ISO_FILE_READ_ERROR;
        }

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 :)

Thomas




reply via email to

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