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

[gary jiang]

Hi Thomas,

Thanks for your reply at first!
On 2014/11/19 20:49, Thomas Schmitt wrote:
> 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.
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:
>    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.
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:
>    http://www.syslinux.org/archives/2014-June/022334.html
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.
>
> -------------------------------------------------------------
> 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;
>          }
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,
Gary

> 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