# MakeIso

113 replies to this topic

### #51 ambralivio

ambralivio

Frequent Member

• 179 posts
•
Italy

Posted 05 January 2018 - 04:32 PM

No, you haven't (or for whatever reason the board did not refresh, this:

http://reboot.pro/fi...le/582-makeiso/

is still 1.0.0.5

Really, the page was not correctly updated, even if the zip file from download seems to be in the new declared version.

The url to the zip file is always the same and does not need to be updated.

It should aways point to http://erwan.labalec...isk/makeiso.zip.

Wierd : the above 2 lines is my post (Erwan.l) but appears under somebody else nickname

### #52 erwan.l

erwan.l

Gold Member

• Developer
• 2280 posts
• Location:Nantes - France
•
France

Posted 05 January 2018 - 04:34 PM

No, you haven't (or for whatever reason the board did not refresh, this:

http://reboot.pro/fi...le/582-makeiso/

is still 1.0.0.5

Wonko

Oops ...   Busted.

Page refreshed.

### #53 erwan.l

erwan.l

Gold Member

• Developer
• 2280 posts
• Location:Nantes - France
•
France

Posted 05 January 2018 - 04:38 PM

Why?

I mean, you could continue the batch (and use one of your tools or *any* other means) to create and populate the floppy image.

As an example, Gilles Vollant's Freeware Extract can do it:

http://www.winimage.com/extract.htm

*like*:



EXTRACT -i efiboot.img bootia32.efi -F288

or mtools:

http://reboot.pro/fi...ile/267-mtools/

Also, as hinted previously, the fact that the good MS guys use a 2.88 sized floppy it doesn't mean that such a size is actually needed.

Given that the built GRUB2 bootia32.efi and/or bootx64.efi are smaller, a 1.44 and possibly even a 1.2 or even smaller filesystem would be enough (to be tested).

Wonko

Exactly what I was looking for : complete the last part i.e make the floppy image : thanks !

Will update my batch.

### #54 Wonko the Sane

Wonko the Sane

The Finder

• 14212 posts
• Location:The Outside of the Asylum (gate is closed)
•
Italy

Posted 05 January 2018 - 04:43 PM

The url to the zip file is always the same and does not need to be updated.

It should aways point to http://erwan.labalec...isk/makeiso.zip.

I know , but was just pointing out that erwan.l's theoretically magnificent plan to use senselessly same named files can (and has, and will) fail nonetheless in practice.

@erwan.l

In next release, remember to add also the /grub/i386-efi/ subdir ...

Wonko

### #55 erwan.l

erwan.l

Gold Member

• Developer
• 2280 posts
• Location:Nantes - France
•
France

Posted 05 January 2018 - 04:56 PM

I know , but was just pointing out that erwan.l's theoretically magnificent plan to use senselessly same named files can (and has, and will) fail nonetheless in practice.

@erwan.l

In next release, remember to add also the /grub/i386-efi/ subdir ...

Wonko

"Touché"

Nice catch about grub efi folders : zip re uploaded (and makeiso version untouched).

Frequent Member

• 155 posts

Posted 05 January 2018 - 05:32 PM

From what you report (actually from what I understand of your report), the 2 Kb size is correct and same as mkisofs -boot-load-size 4 (that is the whole point of boot info table).
As said earlier (at length) the point is all about compatibility with some (nowadays "older") systems/BIOSes that "assume" that the no-emulation boot image is 2 Kb.
It is normally a choice with mkisofs, the -boot-load-size 4 (and thus the use of boot info table) hopefully assures booting on a wider range of systems.

That's why I performed the VM test with both ISO images, one created with MakeIso 1.0.0.6 and the other with another tool. In both cases, the information shown by Isobuster matched the respective behaviors when testing in a VM.

With MakeIso 1.0.0.6, Isobuster shows the El Torito boot image size as 2KiB, and the ISO image fails to boot (with ISOLINUX's checksum error). With the other tool, Isobuster shows the expected size and the ISO image boots the VM correctly.

### #57 erwan.l

erwan.l

Gold Member

• Developer
• 2280 posts
• Location:Nantes - France
•
France

Posted 05 January 2018 - 05:39 PM

That's why I performed the VM test with both ISO images, one created with MakeIso 1.0.0.6 and the other with another tool. In both cases, the information shown by Isobuster matched the respective behaviors when testing in a VM.

With MakeIso 1.0.0.6, Isobuster shows the El Torito boot image size as 2KiB, and the ISO image fails to boot (with ISOLINUX's checksum error). With the other tool, Isobuster shows the expected size and the ISO image boots the VM correctly.

There should be a log file generated in the makeiso folder : can you share it with me?

Also, if you can send me a iso_info file.iso, it will help me troubleshoot.

Last, can you point me to which isolinux you have used?

### #58 Wonko the Sane

Wonko the Sane

The Finder

• 14212 posts
• Location:The Outside of the Asylum (gate is closed)
•
Italy

Posted 05 January 2018 - 06:18 PM

Yep, but the point is that - specifically and in this case only - some info is missing and Isobuster - exceptionally - is not the "right tool" to check (for some reasons)

Can you name the "other" tool?

Can you specify the exact (command line or GUI) options you used for running the test?

Or, can you create two (small, containing just the isolinux bootable file) images with makeiso and the other tool and upload them somewhere, providing a link?

Or, can you do a FC between the first sector of the "source" isolinux and the first sector of the IsoLinux actually "burned" by makeiso and the first sector of the Isolinux "burned" by the other unnamed tool?

@erwan.l

Whilst (for other reasons) your tool iso_info is not reliable.  (heck, you wrote it, and if something is wrong in the concept - not only in the implementation - of makeiso, likely the same error has been made in iso_info )

Theory of operation :

makeiso does not touch the bootinfotable (that shouldn't be touched as it is ALREADY compiled correctly in Isolinux, at least in the versions I tested at the time with Isobuster's Author) AND Isobuster thus lists the correct size (because it checks bootinfotable)

I mean, without knowing the details ALL of these are possible, as seen from here:

1) makeiso does corrupt the preexisting correct bootinfotable and THUS Isobuster lists NOT the correct size but defaults to 2 K

2) the other tool uses NOT the -boot-load-size 4 (or similar) and thus it doesn't touch the bootinfotable BUT ALSO does not set the size to 2K AND THUS Isobuster reads the "plain" size of the file

3) the other tool uses the -boot-load-size 4 (or similar) and anyway doesn't touch the bootinfotable AND the IsoBuster reads correctly the bootinfotable

4) the whatever version of Isolinux has a "wrong" bootinfotable and mkisofs correctly doesn't change it (but also doesn't verify it) ...

5) the other tool uses the -boot-load-size 4 (or similar) AND also the -boot-info-table (or similar) and thus overwrites (correctly) the bootinfotable AND the IsoBuster reads correctly the bootinfotable

The most probable is #1, you should know if you implemented any change to the bootinfotable, but also #4 (and the consequent #5 are possible).

Wonko

Frequent Member

• 155 posts

Posted 05 January 2018 - 06:24 PM

I am trying to catch up with the requested info :).

MakeIso 1.0.0.6 log:
19:44:13:653 , makeiso
C:\Path\to\source\dir
C:\Path\to\source\dir\isolinux.bin

C:\Path\to\source\temp.iso
1
4
19:44:18:455 , makeiso OK

Part of isoinfo.exe 3.01a07:
isoinfo.exe -d -debug -i "C:\Path\to\source\temp.iso"

CD-ROM is in ISO 9660 format
System id:
Volume id: DISK
Volume set id: DISK
Publisher id:
Data preparer id: IMAPI2 (1.0) ISO9660 FORMATTER COPYRIGHT (C) 2004-2007 MICROSO
FT
Application id:
Abstract File id:
Bibliographic File id:
Volume set size is: 1
Volume set sequence number is: 1
Logical block size is: 2048
Volume size is: 4083
Root directory extent:  23 size: 4464
Path table size is:     10
L Path table start:     21
L Path opt table start: 0
M Path table start:     22
M Path opt table start: 0
Creation Date:     2018 01 05 14:48:33.00
Modification Date: 0000 00 00 00:00:00.00
Expiration Date:   0000 00 00 00:00:00.00
Effective Date:    0000 00 00 00:00:00.00
File structure version: 1
El Torito VD version 1 found, boot catalog is in sector 19
NO Joliet present

No SUSP/Rock Ridge present
Hid 1
Arch 0 (x86)
ID 'Microsoft'
Cksum A8 9F OK
Key 55 AA
Bootid 88 (bootable)
Boot media 0 (No Emulation Boot)
Sys type 0
Nsect 4
Bootoff 14 20

Part of xorriso -report_el_torito :
...

Found hidden El-Torito image. Its size could not be figured
out, so image modify or boot image patching may lead to bad results.

...

xorriso : SORRY : Cannot enable EL Torito boot image #1 because it is not a data
file in the ISO filesystem

...

--boot-catalog-hide
xorriso : NOTE : Tolerated problem event of severity 'SORRY'
xorriso : NOTE : -return_with SORRY 32 triggered by problem severity SORRY


Please note the "patching" term (which reminds me of the "patch boot table" options in some ISO-building tools.

In contrast, the ISO image that I built from the same source directory with a different tool:
...
--boot-catalog-hide
-b '/isolinux.bin'
-no-emul-boot
-boot-info-table

The isolinux.bin version happens to be official upstream 6.03.

HTH.

### #60 Wonko the Sane

Wonko the Sane

The Finder

• 14212 posts
• Location:The Outside of the Asylum (gate is closed)
•
Italy

Posted 05 January 2018 - 06:43 PM

@Erwan.l

And to add a random data point, makeiso 1.0.0.6 doesn't run on my XP, sporting a "nice" "Interface not supported" message.

Now, if I had access to a previous version (as opposed to having the same file name) I could do more tests.

As a matter of fact I have (smartly )  a previously saved 1.0.0.15 and it behaves the same.

Maybe it is not intended for XP at all?

As a side note, when the program starts, it will seemingly attempt to create an UDF (non-bootable) .iso image of C:\ (stored into C: itself as C:\temp.iso)

Hopefully there is in the program some safety to avoid this kind of recursion, as in this particular case pre-populating the fields in this way doesn't seem to be particularly smart.

I'll check if it is an issue with IMAPI version I have (cannot remember if I updated this particular install), however a more meaningful error message may be of use.

Wonko

Frequent Member

• 155 posts

Posted 05 January 2018 - 06:49 PM

New tests, new ISO images, with isolinux-debug.bin 4.07 (renamed as isolinux.bin).

Initial bytes from isolinux-debug.bin 4.07 within ISO image created by MakeIso 1.0.0.6:
FA EA 40 7C 00 00 90 90 10 00 00 00 00 00 00 00 00 60 00 00 F8 B7 35 E7 EF BE AD DE EF BE AD DE EF BE AD DE EF BE AD DE EF BE AD DE EF BE AD DE EF BE AD DE EF BE AD DE EF BE AD DE EF BE AD DE

Initial bytes from isolinux-debug.bin 4.07 within ISO image created by ImgBurn:
FA EA 40 7C 00 00 90 90 10 00 00 00 4C 02 00 00 00 60 00 00 BA D9 3F 6A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Although some bytes of isolinux.bin are always modified when creating an ISO image, the above seems to be pointing to some pattern.

BTW, the OS I am currently using for tests is one of those no-longer supported by Microsoft (so, older than Seven+SPs).

### #62 erwan.l

erwan.l

Gold Member

• Developer
• 2280 posts
• Location:Nantes - France
•
France

Posted 05 January 2018 - 07:06 PM

New tests, new ISO images, with isolinux-debug.bin 4.07 (renamed as isolinux.bin).

Initial bytes from isolinux-debug.bin 4.07 within ISO image created by MakeIso 1.0.0.6:

FA EA 40 7C 00 00 90 90 10 00 00 00 00 00 00 00 00 60 00 00 F8 B7 35 E7 EF BE AD DE EF BE AD DE EF BE AD DE EF BE AD DE EF BE AD DE EF BE AD DE EF BE AD DE EF BE AD DE EF BE AD DE EF BE AD DE

Initial bytes from isolinux-debug.bin 4.07 within ISO image created by ImgBurn:
FA EA 40 7C 00 00 90 90 10 00 00 00 4C 02 00 00 00 60 00 00 BA D9 3F 6A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Although some bytes of isolinux.bin are always modified when creating an ISO image, the above seems to be pointing to some pattern.

BTW, the OS I am currently using for tests is one of those no-longer supported by Microsoft (so, older than Seven+SPs).

Can you make sure you use "UDF" (only) as a filesystem?

I am on a path there... do not select any other filesystem for now (when dealing with a boot loader requiring the boot table to be updated).

Frequent Member

• 155 posts

Posted 05 January 2018 - 07:07 PM

In the first isoinfo.exe 3.01a07 report (which I posted in a prior post) of the ISO image created by MakeIso 1.0.0.6 (containing isolinux.bin 6.03), the following sounds relevant to the issue:
Bootoff 14 20

"14 20" sound "too-low" values, as if it is immediately after the boot catalog, but "too immediately" :). I would had expected a higher set of values. I hope I am not introducing noise with this vague comment.

### #64 erwan.l

erwan.l

Gold Member

• Developer
• 2280 posts
• Location:Nantes - France
•
France

Posted 05 January 2018 - 07:07 PM

@Erwan.l

And to add a random data point, makeiso 1.0.0.6 doesn't run on my XP, sporting a "nice" "Interface not supported" message.

Now, if I had access to a previous version (as opposed to having the same file name) I could do more tests.

As a matter of fact I have (smartly )  a previously saved 1.0.0.15 and it behaves the same.

Maybe it is not intended for XP at all?

As a side note, when the program starts, it will seemingly attempt to create an UDF (non-bootable) .iso image of C:\ (stored into C: itself as C:\temp.iso)

Hopefully there is in the program some safety to avoid this kind of recursion, as in this particular case pre-populating the fields in this way doesn't seem to be particularly smart.

I'll check if it is an issue with IMAPI version I have (cannot remember if I updated this particular install), however a more meaningful error message may be of use.

Wonko

Actually, because I am generating a multi boot iso file, I have to go for a COM object interface which is not supported on XP.

Now I could make it so that it will work on XP if you select one boot file only.

But really? XP?

You are asking for troubles there.

About fields pre populated, it is "only" text, the program does not do anything until you actually ask for it.

But I could leave them empty - only I think it is nice to spare the user some extra work?

Frequent Member

• 155 posts

Posted 05 January 2018 - 07:13 PM

Can you make sure you use "UDF" (only) as a filesystem?

There you go, with UDF, Isobuster shows the correct El Torito size. I have not yet tested the result in a VM, but we have progress now. Prior tests were performed using ISO9660 alone.

### #66 erwan.l

erwan.l

Gold Member

• Developer
• 2280 posts
• Location:Nantes - France
•
France

Posted 05 January 2018 - 07:14 PM

There you go, with UDF, Isobuster shows the correct El Torito size. I have not yet tested the result in a VM, but we have progress now. Prior tests were performed using ISO9660 alone.

My bad actually, I meant ISO9660 only...

Sorry...

You want to see something like "18:37:01:525 , patch_iso9660_boot_file OK" in the log file or else it means the boot table is not taken care of.

For now, it appears I need a specific routine (only for boot loaders having a boot-table) for non filesystems other than ISO9660

Frequent Member

• 155 posts

Posted 05 January 2018 - 07:26 PM

My bad actually, I meant ISO9660 only...

As I said, that's what I was using in my prior tests. BTW, remember that ISOLINUX needs ISO9660 to be present (whether alone or with others, such as UDF); using UDF alone will not work with ISOLINUX.

At any rate, with UDF alone in MakeIso 1.0.0.6, the El Torito size was reported correctly in Isobuster.

Sorry...
You want to see something like "18:37:01:525 , patch_iso9660_boot_file OK" in the log file or else it means the boot table is not taken care of.

As reported in a prior post, I don't see such sentence, only what I reported. It also matches what xorriso and isoinfo reported (no patching was actually performed by MakeIso 1.0.0.6 when only ISO9660 was selected; see my prior posts, when I mentioned the "patching" term).

### #68 erwan.l

erwan.l

Gold Member

• Developer
• 2280 posts
• Location:Nantes - France
•
France

Posted 05 January 2018 - 07:27 PM

Also, i foresee issue with the '-' in your isolinux-debug filename due to level=1.

Summary on this issue :

-stick to ISO9660

-stick to 8.1 filename

interchangelevel=2 was already a bit of annoying to deal with but your OS being older, only interchangelevel=1  is supported.

As a whole, ISO9660 support in IMAPI is extremely limited

I will ultimately get around it but this is very disapointing.

### #69 erwan.l

erwan.l

Gold Member

• Developer
• 2280 posts
• Location:Nantes - France
•
France

Posted 05 January 2018 - 07:29 PM

As I said, that's what I was using in my prior tests. BTW, remember that ISOLINUX needs ISO9660 to be present (whether alone or with others, such as UDF); using UDF alone will not work with ISOLINUX.

At any rate, with UDF alone in MakeIso 1.0.0.6, the El Torito size was reported correctly in Isobuster.

As reported in a prior post, I don't see such sentence, only what I reported. It also matches what xorriso and isoinfo reported (no patching was actually performed by MakeIso 1.0.0.6 when only ISO9660 was selected; see my prior posts, when I mentioned the "patching" term).

yep, your reports are all consistent :

-in UDF mode, I write the whole isolinux to the boot sector which is known to work but this is not "by the book" - doing so (stuffing it all in the boot sector), you dont need to patch the boot table.

-in ISO9660, i started it to do it by the book (patching the boot table, writing only 4 sectors, pointing to the file lba, etc) - but as your OS only supports interchangelevel=1, it does introduce other side effects.

it may very well be that if you go a 8 chars filename, the boot table will again be taken care of (and you will see it in the log file).

Frequent Member

• 155 posts

Posted 05 January 2018 - 07:36 PM

Also, i foresee issue with the '-' in your isolinux-debug filename due to level=1.

As I said, I renamed it to "isolinux.bin" (conforms ISO9660 Level1) before creating the ISO image.

interchangelevel=2 was already a bit of annoying to deal with but your OS being older, only interchangelevel=1  is supported.
As a whole, ISO9660 support in IMAPI is extremely limited :(
I will ultimately get around it but this is very disapointing.

Would you consider using some other source instead of IMAPI? Perhaps "libcdio"? It has its own issues, but ISO9660 Level3 is not one of them (I think).

### #71 Wonko the Sane

Wonko the Sane

The Finder

• 14212 posts
• Location:The Outside of the Asylum (gate is closed)
•
Italy

Posted 05 January 2018 - 07:51 PM

Hmmm.
Sometimes I have this deja vu feeling.
http://www.msfn.org/...-torito-images/

Why would jaclaz over there have created the Isolinux_versions.xls?
http://www.msfn.org/...comment=1085396

I am attaching a copy just in case.

Why would the good Peter Anvin have written:

; This table hopefully gets filled in by mkisofs using the
; -boot-info-table option. If not, the values in this
; table are default values that we can use to get us what
; we need, at least under a certain set of assumptions.
bi_pvd: dd 16 ; LBA of primary volume descriptor
bi_file: dd 0 ; LBA of boot file
bi_length: dd 0xdeadbeef ; Length of boot file
bi_csum: dd 0xdeadbeef ; Checksum of boot file
bi_reserved: times 10 dd 0xdeadbeef ; Reserved
bi_end:

So the news are that IMGBURN is modifying the ISOLINUX file, against the (IMHO evident) intention of the Author, but seemingly the checksum is recalculated correctly and everything works nonetheless.

An UNTOUCHED Isolinux.bin 4.07 (that works just fine, without any need to change any byte in it) is:



FA EA 6C 7C 00 00 90 90 10 00 00 00 00 00 00 00
00 60 00 00 34 C6 23 0E EF BE AD DE EF BE AD DE
EF BE AD DE EF BE AD DE EF BE AD DE EF BE AD DE
EF BE AD DE EF BE AD DE EF BE AD DE EF BE AD DE


and the corresponding isolinux-debug.bin (that again should work just fine without changing any byte in it):



FA EA 40 7C 00 00 90 90 10 00 00 00 00 00 00 00
00 60 00 00 F8 B7 35 E7 EF BE AD DE EF BE AD DE
EF BE AD DE EF BE AD DE EF BE AD DE EF BE AD DE
EF BE AD DE EF BE AD DE EF BE AD DE EF BE AD DE



So the issue is not there (unless some other bytes are changed by makeiso and the checksum becomes invalid).

But, AGAIN, makeiso should IMHO leave the pre-made by the Author bootinfotable alone, which is the actual "by the book".

Wonko

### #72 erwan.l

erwan.l

Gold Member

• Developer
• 2280 posts
• Location:Nantes - France
•
France

Posted 05 January 2018 - 07:54 PM

As I said, I renamed it to "isolinux.bin" (conforms ISO9660 Level1) before creating the ISO image.

Would you consider using some other source instead of IMAPI? Perhaps "libcdio"? It has its own issues, but ISO9660 Level3 is not one of them (I think).

I was afraid you would say that

Indeed IMAPI is quite disapointing : sounds appealing at first as it is easy to implement, natively part of windows, etc.

As I dont like to drop a project in the middle of it, I will take on board current reported issues and will quickly call it a final version.

On the positive side, if you take away the lack of support for ISO9660, I still find it handy to have a piece of code which I can quickly stuff in any of my projects so, not a pure waste of time

### #73 erwan.l

erwan.l

Gold Member

• Developer
• 2280 posts
• Location:Nantes - France
•
France

Posted 05 January 2018 - 07:56 PM

So the issue is not there (unless some other bytes are changed by makeiso and the checksum becomes invalid).

The file lba i.e where should the boot code (stage1?) look for for the rest of the booting code (stage2)?

Situation is as is for now :

-In UDF mode, MakeIso will not bother about the boot table (for isolinux in our case) and will write all byes in the boot sector.

The ISO will therefore boot OK (with isolinux) although this is not correct according to specs.

Note that to my experience, this does not work Grub2 (it needs a valid boot table).

-in ISO9660 level 2, only 4 bytes will be written and the boot table will point to the file lba found in the directory : that works for Isolinux but also for Grub2

-in ISO9660 level 1, only 4 bytes will be written and the boot table will NOT be handled leaving to a non bootable ISO

As for XP, it would be rather easy to make it work with only one limitation : only one boot file will be supported.

### #74 erwan.l

erwan.l

Gold Member

• Developer
• 2280 posts
• Location:Nantes - France
•
France

Posted 05 January 2018 - 08:07 PM

1.0.0.7
no more using the boot table for isolinux : writing it all to the boot sector

I drop the ball for now on isolinux and its boot table.

Will just stuff it all in the boot sector like many softwares out there.

### #75 erwan.l

erwan.l

Gold Member

• Developer
• 2280 posts
• Location:Nantes - France
•
France

Posted 05 January 2018 - 08:23 PM

In the first isoinfo.exe 3.01a07 report (which I posted in a prior post) of the ISO image created by MakeIso 1.0.0.6 (containing isolinux.bin 6.03), the following sounds relevant to the issue:

Bootoff 14 20

"14 20" sound "too-low" values, as if it is immediately after the boot catalog, but "too immediately" . I would had expected a higher set of values. I hope I am not introducing noise with this vague comment.

just realised you may be right there.

double checking.

I believe I'll stop for today.

Imapi is a b....

All it really does well is write files to a udf/joliet volume.

Writing files to a ISO9660 is limited and all boot loaders I have encountered (even the MS one) needs some sort of tweaking

Enough for one day, back to some other more fun topics.

#### 0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users