Jump to content











Photo
- - - - -

MakeIso


  • Please log in to reply
102 replies to this topic

#1 erwan.l

erwan.l

    Gold Member

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

Posted 28 December 2017 - 01:52 PM

Posted Image

File Name: MakeIso
File Submitter: erwan.l
File Submitted: 28 Dec 2017
File Updated: 12 Jan 2018
File Category: Tools

MakeIso will create an ISO from a source folder.

Supports multi-boot iso : x86 and EFI.
Support ISO9660, UDF, Joliet or any combination of these 3 filesystems.
Supports isolinux (checksum will be taken care of).
Tested successfully with Grub4Dos.

Mkiso is native (no external dependencies), standalone, built in on windows builtin imapi2.

MkIso is also part of CloneDisk.

Questions, feedback, requests welcome.

Regards,
Erwan

Click here to download this file
  • Nuno Brito and ktp like this

#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14075 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 28 December 2017 - 05:38 PM

Since (more or less) the tool is not a "general" iso making tool, maybe renaming it MkPEisoGUI or something similar, *somehow* conveying that:

1) it is mainly[1] for creating Windows PE iso's

2) it is a GUI tool

might be a good idea, the current mkiso name is IMHO too similar to good ol' mkisofs (that is generic and commandline).

 

:duff:

Wonko

 

[1] When/if you will have tested it succesfully with El-Torito floppy emulation and hard disk emulation, and of course all .iso levels, I will gladly remove the "mainly" ;)

 

As a side-side note, if you "interface" directly with imapi, when you will have your next attack of featuritis :w00t: :ph34r: ,re:

http://reboot.pro/to...edisk/?p=196390

 

what is missing right now (unless I missed it) is a reliable tool (GUI) capable of creating El-Torito floppy emulation bootable .iso's with super-floppies, JFYI:

http://www.msfn.org/...oppy-emulation/

At the time I found a tool that worked (but needed a binnary patch on the result):

http://www.msfn.org/...&comment=971260

and one that worked "as is" but is now defunct:

http://www.msfn.org/...&comment=971380

 

Just for the record the (known to only a few people and now also not available) version of mkisoFS by cdob does actually allow that:

http://www.msfn.org/...comment=1033412

and that can still be found here as attachment:

http://reboot.pro/to...e-2#entry189483

I haven't checked if newer builds take this into account. :unsure.



#3 erwan.l

erwan.l

    Gold Member

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

Posted 28 December 2017 - 06:38 PM

Thanks for this helpful feedback as always.

 

About the "PE" aspect, I am not sure actually : i believe that tool can be used for any purpose, not only Winpe projects.

 

About the name, I must confess : i was pretty dry there.

"mkiso" is derived from MakeIso, similar to the old good MakePE tool here on this forum.

 

About the floppy/disk emlulation, mkiso (thru imapi2) can do it but I have hidden these features for now as I had no practical case to try out.

Furthermore, I wanted to keep the interface as simple as possible (to start with :) ).

 

Now... about featuritis ... well, you know me for some years now ... although I am trying to listen to your good advices, I am afraid this is in my genes :)

I do my very best to keep things simple but my "strategy" for a while now is to work on one particular feature (pxe booting, disk imaging, ...) and stretch it over and over (clonedisk is one example).

Thus, to keep each item easy to reach for end users, I also release tools individually : DiskMgr, VolumeMgr, MkIso, etc ..

This way, the user has the ability to stay focused on one particular feature without having to discover a "big beast" like CloneDisk.



#4 erwan.l

erwan.l

    Gold Member

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

Posted 28 December 2017 - 10:24 PM

 

 

[1] When/if you will have tested it succesfully with El-Torito floppy emulation and hard disk emulation, and of course all .iso levels, I will gladly remove the "mainly" ;)

 

 

 

what is missing right now (unless I missed it) is a reliable tool (GUI) capable of creating El-Torito floppy emulation bootable .iso's with super-floppies, JFYI:

http://www.msfn.org/...oppy-emulation/

At the time I found a tool that worked (but needed a binnary patch on the result):

http://www.msfn.org/...&comment=971260

and one that worked "as is" but is now defunct:

http://www.msfn.org/...&comment=971380

 

Just for the record the (known to only a few people and now also not available) version of mkisoFS by cdob does actually allow that:

http://www.msfn.org/...comment=1033412

and that can still be found here as attachment:

http://reboot.pro/to...e-2#entry189483

I haven't checked if newer builds take this into account. :unsure.

 

About floppy/harddisk emulation, I have enabled a "hidden" (or not so obvious) feature in latest version. (see below).

For now, I keep the GUI as simple as possible at first look (hence the hidden right click menu on the boot file selection button).

 

I have quickly tried with a freedos floppy and I get a bootable iso thus I am not sure yet what to really test...

Or may be I am not getting the "super" floppy concept.

Will look deeper in the links you provided.

EDIT : got it - 36Mb super floppy disks ... not on my todo list indeed - will stick to the 1.2/1.44/2.88/harddisk emulation types.

In the meantime, if you care about trying this floppy/harddisk emulation with MkIso, be my guest :)

 

Side note : when using efisys.bin (which happens to be a floppy), EmulationNone works fine.

I am confused now : should not it be Emulation144MFloppy?

 

HIuwsHT.png



#5 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14075 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 29 December 2017 - 10:16 AM

Side note : when using efisys.bin (which happens to be a floppy), EmulationNone works fine.
I am confused now : should not it be Emulation144MFloppy?

No, not really.
The "normal" or "intended" behaviour of the El-Torito floppy emulation was that of floppy emulation (on BIOS).
The result is similar to having a dual LUN device.
The floppy disk is a "separate" device that gets its own drive letter and - for all the BIOS knows - is a (read only) bootable floppy drive.
As a matter of fact it is the simplest possible booting method, the (emulated) floppy is mounted/accessed as "first floppy" (please read as (fd0) or drive #0 or A: if you prefer) and its bootsector is chainloaded by the BIOS just as if it was a "normal" floppy.
For some time it was the only available method to boot CD's (I am talking here of DOS and NT 3.5/early 4.0 times) as many BIOSes were not compatible with the "no-emulation" mode that MS adopted for non-DOS botable CD's.
In the good ol' times the NT 4.0 install CD was not even bootable and it came (from MS) with three floppies, you booted from the first floppy, read the other two and only then you would start accessing (hopefully) the CD.
Moreover at the time the access to *any* device was - at least as BIOS level - in CHS (and not LBA) mode, so the geometry was important and BIOSes has already suitable CHS code for floppies formats.

As mentioned on the given thread, and here:
http://reboot.pro/to...brided/?p=86679
the good guys at MenuetOS took this concept a step further, putting together the simpler possible way to create a bootabloe .iso, that is ONLY a bootable emulated floppy (with no CDFS or UDF filesystem attached).


The efisys.bin, that the good MS guys arbitrarily decided to make with the same size as a floppy disk is instead intended for UEFI/EFI only, and it behaves as a "searchable filesystem", there is no reason why it should be this or that size or have this or that geometry.
The UEFI "sees" a filesystem and looks in it for either BOOTX64.EFI or a BOOTIA32.EFI (hardcoded names for UEFI bootfiles).

About superfloppies, it will cost you nothing to add them.
The point is that El-Torito allows for three types of floppies, the details are here, JFYI:
http://www.msfn.org/...&comment=972183

0x1=1200 K i.e. 80/2/15
0x2=1440 K i.e. 80/2/18

0x3=2880 K i.e. 80/2/36


That were actually implemented in all BIOS tested as:

0x1=m/2/15
0x2=n/2/18

0x3=o/2/36


the issue is that most iso making tools (where the programmers have been either as royalist as or more royalist than the king) do check the actual size of the file provided for "floppy emulation" and, if it doesn't correspond to the "standard" size, throws an error.

So, if your tool allows *any* size of the file for "Bootfile", it already works just fine for superfloppies, if there is a check for sizes, then either removing it altogether or offering an option to remove it would be enough.

As a side note:
Boot File (X86)
should really be either of:
Boot File (El-Torito)
or (IMHO better)
Boot File (BIOS)

If you prefer, a UEFI machine with CSM (please read BIOS) enabled should boot out of that file even if the contents are X64 (or whatever).

:duff:
Wonko

#6 cdob

cdob

    Gold Member

  • Expert
  • 1372 posts

Posted 29 December 2017 - 10:59 AM

Side note : when using efisys.bin (which happens to be a floppy), EmulationNone works fine.
I am confused now : should not it be Emulation144MFloppy?

Yes, it's confusing. Use "no emulation" mode
.
The UEFI Specification Version 2.7, section 13.3.2.1 ISO-9660 and El Torito, requests 'an EFI System partition is stored in a "no emulation" mode'
http://www.uefi.org/specifications

#7 erwan.l

erwan.l

    Gold Member

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

Posted 29 December 2017 - 12:10 PM

I have renamed MkIso to MakeIso to avoid confusion with mkisofs.

 

I checked imapi2 and super floppies : in Emulation288MFloppy mode, it wont accept images bigger than 2949120 bytes.

There may be a way around this limitation, I might look into it later on.

 

About "Boot File (X86)", I am merely reusing MS wording (here) but indeed, "Boot File (BIOS)" would be more suited.

Will change this.



#8 erwan.l

erwan.l

    Gold Member

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

Posted 29 December 2017 - 12:53 PM

@Wonko,@CDOB: any el torrito parser you could recommend?

I will look at el torrito specs but having a tool parse an iso header would help better understand an iso and possibly come with a few extra features, workarounds, etc.

 

Thanks !



#9 cdob

cdob

    Gold Member

  • Expert
  • 1372 posts

Posted 29 December 2017 - 04:06 PM

Doing random test I got a "ole error c0aab132"?

Data file is too large for '%1!ls!' file system.
IMAPI Return Values
http://msdn.microsof...y/cc835244.aspx
IMAPI_E_DATA_TOO_BIG
(HRESULT)0xC0AAB132

ISO9660+UDF and a 3,8 GB install.wim.
IMAPI is limited, the manucafturer can't read and interpret ISO9660:1988
https://www.iso.org/...dard/17505.html
PB file size are possible at ISO9660:1988
Works fine at UDF only, that's good.
Default setting was UDF only, I changed it to ISO9660+UDF. My fault.

Question:
Can you add more help texts like "IMAPI_E_DATA_TOO_BIG"?
Or a link to the "IMAPI Return Values"?


ISO9660 only:
Error message: CDBOOT: Couldn't find BOOTMGR
There is a file 'BOOTMGR.' Recognice the leading dot.
ISO9660 Level 1 requires a leading dot.
Compare ECMA-119
https://www.ecma-int...ds/Ecma-119.htm

Can you try put_ISO9660InterchangeLevel method = 3
https://msdn.microso...y/aa365751.aspx

IsoBuster free shows names and el torrito.
Compare IsoBuster License models https://www.isobuste...ense-models.php

In doubt, use a HexEditor.

#10 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14075 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 29 December 2017 - 04:23 PM

Nothing really like a useful "detailed" parser that I know of :unsure:.

 

Isoinfo (part of cdrecord/cdrtools) does provide some, but only little, info.

 

I personally use (though it is not a parser and needs some minimal time to get familiar with it) to check .iso's the tool Isobuster:

https://www.isobuster.com/

it is Commercial, but the free/trial version is enough to quickly check a .iso structure. 

 

The good ol' "reference" tool, which was CDmage is discontinued and unmaintained, so that it won't be good for anything EFI/UEFI and UDF related, just in case:

http://www.softpedia...s/CD-Mage.shtml

 

There are more than a few python scripts available, but last time I checked them (with all due respect for their Authors) they seemed to me either incomplete or too "narrow" to be of any practical use, the exception is 

https://clalancette.github.io/pycdlib/

which is an almost complete library (even "too much" for this use) whilst the "companion tool" pycdlib-explorer:

https://clalancette....b-explorer.html

is more file oriented than "iso structure" oriented.

 

:duff:

Wonko



#11 ady

ady

    Frequent Member

  • Advanced user
  • 155 posts

Posted 29 December 2017 - 04:28 PM

any el torrito parser you could recommend?


A_ At least part of the information of an ISO image, including at least some of the El Torrito info, could be obtained by "isoinfo(.exe)", part of cdrtools.

Example:
 
isoinfo.exe -d -debug -i filename.iso
CD-ROM is in ISO 9660 format
System id:
Volume id: ISOIMAGE
Volume set id:
Publisher id:
Data preparer id: XORRISO-1.4.6 2016.09.16.133001, LIBISOBURN-1.4.6, LIBISOFS-1.
4.6, LIBBURN-1.4.6
Application id:
Copyright File 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: 15026
Root directory extent:  20 size: 6144
Path table size is:     64
L Path table start:     43
L Path opt table start: 0
M Path table start:     44
M Path opt table start: 0
Creation Date:     2017 12 05 15:53:37.00
Modification Date: 2017 12 05 15:53:37.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 59
Joliet escape sequence 0: '%' 1: '/' 2: 'E' 3: ' '
Joliet escape sequence 0: '%' 1: '/' 2: 'E' 3: ' '

Joliet with UCS level 3 found.
SUSP signatures version 1 found
Rock Ridge signatures version 1 found
Rock Ridge id 'RRIP_1991A'
Eltorito validation header:
    Hid 1
    Arch 0 (x86)
    ID ''
    Cksum AA 55 OK
    Key 55 AA
    Eltorito defaultboot header:
        Bootid 88 (bootable)
        Boot media 0 (No Emulation Boot)
        Load segment 0
        Sys type 0
        Nsect 4
        Bootoff DC 220
Please note that the above last item, "Eltorito defaultboot header" shows the _default_ header only; I happen to know that the same ISO image also includes at least 1 additional header (for EFI boot).

Additional or different information might be obtained perhaps by combining other isoinfo command line options.


B_ xorriso might be used in order to obtain El Torito information from ISO images. For instance:
 
xorriso -indev filename.iso -report_el_torito plain

xorriso -indev filename.iso -report_el_torito help
xorriso -indev filename.iso -report_el_torito as_mkisofs


"xorriso.exe" is not so easy to obtain (the last version I know of is v. 1.3.4, originally released during December 2013; most modern Linux distributions would provide a newer version, usually with improvements).

BTW, if the last boot entry is pointing to a EFI System Partition (ESP), then size "zero" (0) means "up to the end of the ISO". UEFI specs prescribe this if the ESP (e.g. superfloppy) image is larger than 32 MiB.


Potentially useful links:

Boot Information Table format explained:

http://littlesvr.ca/...toritosuppl.php


Byte level description of boot entry points in ISO 9660 filesystems:

http://bazaar.launch...oot_sectors.txt


Extracting the boot image from a CD/DVD (El Torito):

https://www.codeproj...D-DVD-El-Torito


Isobuster's page, Bootable CD/DVD - El Torito:

https://www.isobuste...bootable_cd_dvd

#12 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14075 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 29 December 2017 - 04:55 PM

@ady

Very good info :) , but this one:


Extracting the boot image from a CD/DVD (El Torito):

https://www.codeproj...D-DVD-El-Torito
 

which is not advised because of the possible issue with boot-size, see:

http://reboot.pro/to...ting-iso-files/

 

:duff:

Wonko



#13 erwan.l

erwan.l

    Gold Member

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

Posted 29 December 2017 - 04:56 PM

Doing random test I got a "ole error c0aab132"?

Data file is too large for '%1!ls!' file system.
IMAPI Return Values
http://msdn.microsof...y/cc835244.aspx
IMAPI_E_DATA_TOO_BIG
(HRESULT)0xC0AAB132

ISO9660+UDF and a 3,8 GB install.wim.
IMAPI is limited, the manucafturer can't read and interpret ISO9660:1988
https://www.iso.org/...dard/17505.html
PB file size are possible at ISO9660:1988
Works fine at UDF only, that's good.
Default setting was UDF only, I changed it to ISO9660+UDF. My fault.

Question:
Can you add more help texts like "IMAPI_E_DATA_TOO_BIG"?
Or a link to the "IMAPI Return Values"?


ISO9660 only:
Error message: CDBOOT: Couldn't find BOOTMGR
There is a file 'BOOTMGR.' Recognice the leading dot.
ISO9660 Level 1 requires a leading dot.
Compare ECMA-119
https://www.ecma-int...ds/Ecma-119.htm

Can you try put_ISO9660InterchangeLevel method = 3
https://msdn.microso...y/aa365751.aspx

IsoBuster free shows names and el torrito.
Compare IsoBuster License models https://www.isobuste...ense-models.php

In doubt, use a HexEditor.

 

Thanks for this useful feedback.

 

Will interpret the imapi error codes.

 

About iso9660, the max supported is iso level 2.

Not sure how I can work around that (patching the iso afterwards is an option?).

 

As a whole, support around iso9660 in imapi2 seems limited.



#14 erwan.l

erwan.l

    Gold Member

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

Posted 30 December 2017 - 09:25 PM

Still looking to improve or correct some issue with MakeIso, I could not get the iso details (my volume descriptor, my boot record, my boot catalog, ...) i was looking for using isoinfo.exe found in cdrtools.

I read thru the specifications posted above and quickly came with the attached command line tool.

 

Running iso_info.exe c:\temp\winre.iso will give the below output.

 

Reading the below was most useful to quickly understand the iso specs :

-Bootable CD-ROM Format Specification

-Standard ECMA-119

-ISO 9660

iso_info 0.1 by erwan2212@gmail.com
*****************************************
Primary volume
Standard Identifier:CD001
System Identifier:
Volume Identifier:DISK
Volume Set Identifier:DISK
Publisher Identifier:
Data Preparer Identifier:IMAPI2 (1.0) ISO9660 FORMATTER COPYRIGHT (C) 2004-2007 MICROSOFT
Application Identifier:
Logical Blocksize:2048
Volume Size:111097 blocks. 216MB
path_table:$00173000 (1519616)
root_directory:$00174000 (1523712)
*****************************************
boot-record-volume
ISO9660_Identifier:CD001
Boot_System_identifier:EL TORITO SPECIFICATION
first_sector_of_Boot_Catalog:$00000013 (38912)
*****************************************
boot-catalog
->Validation Entry [entry #0]
platform_id:0
manufacturer:Microsoft
->Initial/Default Entry
boot_indicator:$88
boot_media_type:0
starting_sector:$00000014 (40960)
virtual_sector_count:$0008 (4096)
->Section Header Entry [entry #1]
header_indicator:$91
platform_id:$EF
Number_of_section_entries:$1
id_string:Microsoft
->Section Entry
boot_indicator:$88
boot_media_type:2
starting_sector:$00000016 (45056)
virtual_sector_count:$0B40 (1474560)

 

Then, one can easily dump a cd boot file by running dsfo winre.iso 45056 1474560 boot.bin.

Attached Files



#15 erwan.l

erwan.l

    Gold Member

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

Posted 30 December 2017 - 10:14 PM

version 1.0.0.2 uploaded.

 

Following an issue reported by Cdob in this post, ISO9660 level 2 now OK with MS cdboot etfsboot.com



#16 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14075 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 31 December 2017 - 10:51 AM

Then, one can easily dump a cd boot file by running dsfo winre.iso 45056 1474560 boot.bin.

Well, though I am one of the major supporters of the DSFOK toolkit :thumbup: , maybe it would be easier to just use 7-zip for that.

 

Otherwise, as noted above, and as a shameless plug ;), I suggest the use of my little batch (which does make use of dsfo) :

http://reboot.pro/to...ting-iso-files/

http://reboot.pro/to...files/?p=108486

 

which covers the cases where the sector numbers for the (no-emulation) bootsector are "faked".

 

:duff:

Wonko



#17 erwan.l

erwan.l

    Gold Member

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

Posted 31 December 2017 - 02:01 PM

Well, though I am one of the major supporters of the DSFOK toolkit :thumbup: , maybe it would be easier to just use 7-zip for that.

 

Otherwise, as noted above, and as a shameless plug ;), I suggest the use of my little batch (which does make use of dsfo) :

http://reboot.pro/to...ting-iso-files/

http://reboot.pro/to...files/?p=108486

 

which covers the cases where the sector numbers for the (no-emulation) bootsector are "faked".

 

:duff:

Wonko

 

Nice thread again, thanks.

 

About the sector count, I had already noticed it was not to be trusted for floppy images.

My iso_info takes care of that on the fly.

I have not yet looked closely at the HD emulation.

 

About isolinux, this is indeed a special case I know of.

sector count is (most of the times?) 4 - the slitaz 3.0 image generated by genisoimage is a good example.

I have not yet gone thru your batch (the one posted in this thread) but my idea was to use the boot table (offset 16 = boot file length).

May be this is what your are doing already? Although a quick look at your batch seems to indicate you are using the iso directory listing.

 

Still about isolinux and the boot table, I am using another (exotic?) approach : i am writing the whole isolinux.bin as a boot file with sector count = whole file size and only take care of the checksum in the boot table (ignoring all other fields).

That works too.



#18 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14075 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 31 December 2017 - 02:27 PM

Yep, the batch only leverages on what you can get from isoinfo, only "automating" the approach cdob suggested here:

http://reboot.pro/to...files/?p=108401

 

If I get right, your reference to "boot table" and "offset 16", and specifically for the Slitaz 3.0 iso it is exactly the boot file size that is "wrong" (on purpose):

http://reboot.pro/to...files/?p=108400

http://reboot.pro/to...files/?p=108391

 

Still about isolinux and the boot table, I am using another (exotic?) approach : i am writing the whole isolinux.bin as a boot file with sector count = whole file size and only take care of the checksum in the boot table (ignoring all other fields).

That works too.

That is what you believe.

 

The "switch" in mkisofs:

-boot-load-size 4

is what creates the "wrong" size, but at the time it was introduced because a number of BIOSes simply failed if that size was not 4 in no-emulation mode (again programmers more royalist than the king, likely), see:

https://web.archive....showtopic=20864

posts #16,  #17 and #18

 

:duff:

Wonko



#19 erwan.l

erwan.l

    Gold Member

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

Posted 31 December 2017 - 02:30 PM

Uploading a new version of iso_info which will also eventually display the boot table  (i.e if a valid one found) included in the boot file.

 

If exist a boot table, then the boot file length should be taken from there and not from the sector count found in the boot catalog.

 

I am slightly deviating thus from the main thread which is about MakeIso, i.e making the process as quick and easy as possible to make a (multi) bootable iso.

 

iso_info.exe c:\temp\slitaz-3.0.iso

iso_info 0.2 by erwan2212@gmail.com
*****************************************
Primary volume
Standard Identifier:CD001
System Identifier:LINUX
Volume Identifier:SliTaz core
Volume Set Identifier:
Publisher Identifier:
Data Preparer Identifier:pankso
Application Identifier:GENISOIMAGE ISO 9660/HFS FILESYSTEM CREATOR (C) 1993 E.YOUNGDALE (C) 1997-2006 J.PEARSON/J.SCHILL
ING (C) 2006-2007 CDRKIT TEAM
Logical Blocksize:2048
Volume Size:15161 blocks. 29MB
path_table:$0000A000 (40960)
root_directory:$0000C000 (49152)
*****************************************
boot-record-volume
ISO9660_Identifier:CD001
Boot_System_identifier:EL TORITO SPECIFICATION
first_sector_of_Boot_Catalog:$00000020 (65536)
*****************************************
boot-catalog
->Validation Entry [entry #0]
platform_id:0
manufacturer:
->Initial/Default Entry
boot_indicator:$88
boot_media_type:0
starting_sector:$00000021 (67584)
virtual_sector_count:$0004 (2048)
boot_table.bi_pvd_lba:$00000010 (32768)
boot_table.bi_file_lba:$00000021 (67584)
boot_table.bi_length:14336
boot_table.bi_csum:$D6B05761

Attached Files



#20 erwan.l

erwan.l

    Gold Member

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

Posted 31 December 2017 - 02:40 PM

Yep, the batch only leverages on what you can get from isoinfo, only "automating" the approach cdob suggested here:

http://reboot.pro/to...files/?p=108401

 

If I get right, your reference to "boot table" and "offset 16", and specifically for the Slitaz 3.0 iso it is exactly the boot file size that is "wrong" (on purpose):

http://reboot.pro/to...files/?p=108400

 

 

That is what you believe.

 

The "switch" in mkisofs:

-boot-load-size 4

is what creates the "wrong" size, but at the time it was introduced because a number of BIOSes simply failed if that size was not 4 in no-emulation mode (again programmers more royalist than the king, likely), see:

https://web.archive....showtopic=20864

posts #16,  #17 and #18

 

:duff:

Wonko

 

Ok, thought so : CDOB approach and your batch are indeed based on the file size in the directlory listing.

 

About "boot table" and "offset 16", I see we have a difference of opinion there : double checking however, seems to indicate that this field is to be trusted.

Check my previous post and the new version of iso_info displaying the boot table.

"boot_table.bi_length:14336" is correct.

With this approach, you also dont need to know the boot file name (to search it from the directory listing).

Last but not least, it seems isoinfo (from cdrtools) is ignoring the second boot entry.

 

About -boot-load-size 4, get it now.

I have tested a few machines and I was lucky enough to have a "tolerant" bios who was ok with a sector count>4.

Thus, to stick to specs, I should review my (exotic) approach when handling isolinux (and possibly other boot loader requiring the boot table).

 

Side note : grldr is handled fine by MakeIso and I am currently looking at grub2 now.



#21 erwan.l

erwan.l

    Gold Member

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

Posted 31 December 2017 - 02:50 PM

Yes, it's confusing. Use "no emulation" mode
.
The UEFI Specification Version 2.7, section 13.3.2.1 ISO-9660 and El Torito, requests 'an EFI System partition is stored in a "no emulation" mode'
http://www.uefi.org/specifications

 

Got it.

 

@CDOB.

 

Note for later  (and really no big deal since it boots fine in both modes) : although I instruct IMAPI to use no emulation mode for both my boot files, somewhere in the process, the emulation type for EFI is switched to media type=2 (when I would expect it to be 0).

 

iso_info.exe .\x86\winre.iso

iso_info 0.2 by erwan2212@gmail.com
*****************************************
Primary volume
Standard Identifier:CD001
System Identifier:
Volume Identifier:DISK
Volume Set Identifier:DISK
Publisher Identifier:
Data Preparer Identifier:IMAPI2 (1.0) ISO9660 FORMATTER COPYRIGHT (C) 2004-2007 MICROSOFT
Application Identifier:
Logical Blocksize:2048
Volume Size:111256 blocks. 217MB
path_table:$00173000 (1519616)
root_directory:$00174000 (1523712)
*****************************************
boot-record-volume
ISO9660_Identifier:CD001
Boot_System_identifier:EL TORITO SPECIFICATION
first_sector_of_Boot_Catalog:$00000013 (38912)
*****************************************
boot-catalog
->Validation Entry [entry #0]
platform_id:0
manufacturer:Microsoft
->Initial/Default Entry
boot_indicator:$88
boot_media_type:0
starting_sector:$00000014 (40960)
virtual_sector_count:$0008 (4096)
->Section Header Entry [entry #1]
header_indicator:$91
platform_id:$EF
Number_of_section_entries:$1
id_string:Microsoft
->Section Entry
boot_indicator:$88
boot_media_type:2
starting_sector:$00000016 (45056)
virtual_sector_count:$0B40 (1474560)


#22 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14075 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 31 December 2017 - 03:04 PM

The issue remains about what happens if you have -boot-load-size 4 WITHOUT -boot-info-table (i.e. if the boot-info-table is created or not).

 

Something that may be of interest, still re: "queer" things that happen in the wild:

http://www.msfn.org/...-torito-images/

particularly here:

http://www.msfn.org/...comment=1085365

http://www.msfn.org/...comment=1085403

 

In a nutshell, Isolinux pre-populates it, whilst grub4dos doesn't (and you will never know what a "random" non-2048 bytes bootloader may do, nor whether the people creating the .iso will have used this or that option). 

 

And -still as a continuation of the Acronis particular CD/DVD's - here:

http://www.msfn.org/...oot-on-uefi-pc/

check:

http://reboot.pro/to...-grub2-at-uefi/

 

:duff:

Wonko



#23 erwan.l

erwan.l

    Gold Member

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

Posted 31 December 2017 - 03:19 PM

The issue remains about what happens if you have -boot-load-size 4 WITHOUT -boot-info-table (i.e. if the boot-info-table is created or not).

 

Something that may be of interest, still re: "queer" things that happen in the wild:

http://www.msfn.org/...-torito-images/

particularly here:

http://www.msfn.org/...comment=1085365

http://www.msfn.org/...comment=1085403

 

In a nutshell, Isolinux pre-populates it, whilst grub4dos doesn't (and you will never know what a "random" non-2048 bytes bootloader may do, nor whether the people creating the .iso will have used this or that option). 

 

And -still as a continuation of the Acronis particular CD/DVD's - here:

http://www.msfn.org/...oot-on-uefi-pc/

check:

http://reboot.pro/to...-grub2-at-uefi/

 

:duff:

Wonko

 

Seems I have (re) opened a pandora's box there :)

 

The boot table does not seem so reliable indeed : defining if there is one is one first tricky part, then ensuring values in there are to be trusted is another tricky part.

Oh well, I felt smart for 5 mns :)

 

And now I read that grub4dos also has a boot table (???) but as it is prepopulated most of us (using mkisofs) ignore it?

 

Playing with iso images is "fun" for sure!

 

I'll stop there with my "cheap" iso_info command line tool : objective was for me to get the informations (offset, size, etc) from various headers contained in an iso to develop further MakeIso and deliver proper (or as proper as possible...) ISO's.



#24 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14075 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 31 December 2017 - 04:21 PM

And now I read that grub4dos also has a boot table (???) but as it is prepopulated most of us (using mkisofs) ignore it?

No, it's the other way round.
 
More or less, grub4dos (its boot code) *needs* NOT the boot-info-table (whilst Syslinux/isolinux needs it AND pre-populates it, since 2.12 or so) so grub4dos's one is all 00's, but the good developers decided to keep it as 00's AND reserving the area for unspecified future use:
http://www.msfn.org/...comment=1085403
 
Here is the related grub4dos discussion:
http://reboot.pro/to...oot-info-table/
 
It is fair enough :), after all the boot-info-table is itself a kind of "hack", and this is the reason why it should not be used as a "simple" way for getting the boot file size.
 
The real issue is - as always - to make something foolproof:

A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.


:duff:
Wonko

#25 ady

ady

    Frequent Member

  • Advanced user
  • 155 posts

Posted 31 December 2017 - 06:32 PM

FWIW...

Olof Lagerkvist (author of imdisk, among others) provides in his website a "geteltorito" command line program. Although its goal is not exactly to parse and show the boot catalog nor the (el torito) boot entries, perhaps its source code might help (developers) so as to develop a command line tool for such/similar purpose(s)?

Regarding xorriso and the options I mentioned before... Unfortunately (for Windows' users) the latest version for Windows available at this moment (v.1.3.4) does not support the relevant options ("-report_el_torito" and "-report_system_area") because they were introduced in xorriso v.1.3.8. I can only hope for a newer version/port for Windows' users.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users