ajgor Posted April 13, 2016 Posted April 13, 2016 I was trying to create a UEFI-bootable ISO with ImgBurn, but the ISO can not be booted on UEFI based systems. I tried to boot the generated ISO file on a virtual machine (VirtualBox) and two computers (after transferring ISO to USB drive by Rufus). I tried to create an ISO from extracted contents of the Windows 8.1 PE ISO image. Contents of the original image were extracted by automatic mount to a Windows volume. I tried to do the same with other software (mkisofs) and everything worked, so that the original ISO should be OK. I needed to create an ISO as intermediate step in customizing a pre-compiled Win PE ISO image downloaded from this site. I needed to add my own software (IGLib, IGShell and AnnApp based) to the ISO for testing and deployment. I checked all possible sources (Google, ImgBurn forums and FAQ) but actually did not find any precise instructions about which settings to use to create a UEFI (not legacy BIOS/MBR) compliant ISO. If I want to create a legacy-bootable ISO, everything works fine with the following settings: Emulation Type: None Boot Image: F:\Boot\etfsboot.com Platform ID: 80x86 Load Segment: 07c0 Sectors To Load: 0 Then I wanted to create a UEFI bootable ISO image and it didn't work with any of combinations below (1) without emulation, 2) with hard disk emulation, 3) with floppy emulation): 1) Emulation Type: None Boot Image: F:\efi\microsoft\boot\efisys.bin Platform ID: UEFI Load Segment: 07c0 Sectors To Load: 8 2) Emulation Type: Hard Disk Boot Image: F:\efi\microsoft\boot\efisys.bin Platform ID: UEFI 2) Emulation Type: Floppy Disk (1.44 MB) Boot Image: F:\efi\microsoft\boot\efisys.bin Platform ID: UEFI What settings should I really use to create an ISO that would correctly boot on UEFI schemes? Thank you and best regards, ajgor
ajgor Posted April 14, 2016 Author Posted April 14, 2016 Because I don't want , I also attach the log file below. I 22:29:19 ImgBurn Version 2.5.8.0 started! I 22:29:19 Microsoft Windows 8 Core x64 Edition (6.2, Build 9200) I 22:29:19 Total Physical Memory: 16,654,616 KiB - Available: 11,586,624 KiB I 22:29:19 Initialising SPTI... I 22:29:19 Searching for SCSI / ATAPI devices... I 22:29:19 -> Drive 1 - Info: HL-DT-ST DVDRAM GTA0N 1.00 (E:) (SATA) I 22:29:19 -> Drive 2 - Info: Msft Virtual DVD-ROM 1.0 (F:) (Virtual) I 22:29:19 Found 1 DVD-ROM and 1 DVD±RW/RAM! I 22:32:28 Operation Started! I 22:32:28 Building Image Tree... I 22:32:32 Checking Directory Depth... W 22:32:33 Directory depth exceeds ISO9660 limit of 8 levels! W 22:32:33 Name: '\PortableApps\AOMEI Partition Assistant 5.5.8 Pro Portable\Data\local\meta\@PROGRAMFILESX86@\AOMEI Partition Assistant Pro Edition 5.5\native\' W 22:32:34 Number of directory levels in path: 9 W 22:32:34 Most directory levels in any path: 15 I 22:32:34 Calculating Totals... I 22:32:34 Preparing Image... I 22:32:37 Checking Path Length... I 22:32:37 Contents: 7,351 Files, 1,026 Folders I 22:32:37 Content Type: Data I 22:32:37 Data Type: MODE1/2048 I 22:32:37 File System(s): ISO9660 (Bootable), UDF (1.02) I 22:32:37 Volume Label: Win8.1SE I 22:32:37 Size: 2,310,440,637 bytes I 22:32:37 Sectors: 1,131,947 I 22:32:37 Image Size: 2,340,552,704 bytes I 22:32:37 Image Sectors: 1,142,848 I 22:32:38 Operation Successfully Completed! - Duration: 00:00:09 I 22:32:38 Operation Started! I 22:32:38 Image Contents: 7,351 Files, 1,026 Folders I 22:32:38 Image Sectors: 1,142,848 (MODE1/2048) I 22:32:38 Image Size: 2,340,552,704 bytes I 22:32:38 Image Single Layer Profile: DVD-R/RW (Media Capacity: 2,297,888) I 22:32:38 Image Volume Identifier: Win8.1SE I 22:32:38 Image Volume Set Identifier: 488DB40E00117036 I 22:32:38 Image Application Identifier: IMGBURN V2.5.8.0 - THE ULTIMATE IMAGE BURNER! I 22:32:38 Image Implementation Identifier: ImgBurn I 22:32:38 Image File System(s): ISO9660 (Bootable), UDF (1.02) I 22:32:38 Destination File: D:\VM\bootable\TEST.ISO I 22:32:38 Destination Free Space: 66,680,225,792 Bytes (65,117,408.00 KiB) (63,591.22 MiB) (62.10 GiB) I 22:32:38 Destination File System: NTFS I 22:32:38 File Splitting: Auto I 22:32:38 Writing Image... I 22:33:58 Operation Successfully Completed! - Duration: 00:01:20 I 22:33:58 Average Write Rate: 28,571 KiB/s (21.1x) - Maximum Write Rate: 57,594 KiB/s (42.6x) I 22:39:02 Operation Started! I 22:39:02 Building Image Tree... I 22:39:06 Checking Directory Depth... W 22:39:10 Directory depth exceeds ISO9660 limit of 8 levels! W 22:39:10 Name: '\PortableApps\AOMEI Partition Assistant 5.5.8 Pro Portable\Data\local\meta\@PROGRAMFILESX86@\AOMEI Partition Assistant Pro Edition 5.5\native\' W 22:39:10 Number of directory levels in path: 9 W 22:39:10 Most directory levels in any path: 15 I 22:39:10 Calculating Totals... I 22:39:10 Preparing Image... I 22:39:12 Checking Path Length... I 22:39:12 Contents: 7,351 Files, 1,026 Folders I 22:39:12 Content Type: Data I 22:39:12 Data Type: MODE1/2048 I 22:39:12 File System(s): ISO9660 (Bootable), UDF (1.02) I 22:39:12 Volume Label: Win8.1SE I 22:39:12 Size: 2,310,440,637 bytes I 22:39:12 Sectors: 1,131,947 I 22:39:12 Image Size: 2,340,552,704 bytes I 22:39:12 Image Sectors: 1,142,848 I 22:39:22 Operation Successfully Completed! - Duration: 00:00:19 I 22:39:22 Operation Started! I 22:39:22 Image Contents: 7,351 Files, 1,026 Folders I 22:39:22 Image Sectors: 1,142,848 (MODE1/2048) I 22:39:22 Image Size: 2,340,552,704 bytes I 22:39:22 Image Single Layer Profile: DVD-R/RW (Media Capacity: 2,297,888) I 22:39:22 Image Volume Identifier: Win8.1SE I 22:39:22 Image Volume Set Identifier: 488DB4E100117036 I 22:39:22 Image Application Identifier: IMGBURN V2.5.8.0 - THE ULTIMATE IMAGE BURNER! I 22:39:22 Image Implementation Identifier: ImgBurn I 22:39:22 Image File System(s): ISO9660 (Bootable), UDF (1.02) I 22:39:22 Destination File: D:\VM\bootable\TEST.ISO I 22:39:22 Destination Free Space: 64,339,632,128 Bytes (62,831,672.00 KiB) (61,359.05 MiB) (59.92 GiB) I 22:39:22 Destination File System: NTFS I 22:39:22 File Splitting: Auto I 22:39:22 Writing Image... I 22:39:38 Operation Successfully Completed! - Duration: 00:00:16 I 22:39:38 Average Write Rate: 142,856 KiB/s (105.6x) - Maximum Write Rate: 263,256 KiB/s (194.6x) I 22:46:22 Operation Started! I 22:46:22 Building Image Tree... I 22:46:25 Checking Directory Depth... W 22:46:28 Directory depth exceeds ISO9660 limit of 8 levels! W 22:46:28 Name: '\PortableApps\AOMEI Partition Assistant 5.5.8 Pro Portable\Data\local\meta\@PROGRAMFILESX86@\AOMEI Partition Assistant Pro Edition 5.5\native\' W 22:46:28 Number of directory levels in path: 9 W 22:46:28 Most directory levels in any path: 15 I 22:46:28 Calculating Totals... I 22:46:28 Preparing Image... I 22:46:30 Checking Path Length... I 22:46:30 Contents: 7,351 Files, 1,026 Folders I 22:46:30 Content Type: Data I 22:46:30 Data Type: MODE1/2048 I 22:46:30 File System(s): ISO9660 (Bootable), UDF (1.02) I 22:46:30 Volume Label: Win8.1SE I 22:46:30 Size: 2,310,440,637 bytes I 22:46:30 Sectors: 1,131,947 I 22:46:30 Image Size: 2,340,552,704 bytes I 22:46:30 Image Sectors: 1,142,848 I 22:46:37 Operation Successfully Completed! - Duration: 00:00:14
LIGHTNING UK! Posted April 14, 2016 Posted April 14, 2016 I'd have expected number 1 to work. Which parameters are you passing to mkisofs? That should give us a clue. Beyond that, I'd have to examine a chunk of each image and see how they differ.
ajgor Posted April 14, 2016 Author Posted April 14, 2016 I'm running mkisofs like this: set inputdir=F:\ set outputiso=d:\VM\bootable\TEST.ISO set label="UEFI_BIOS_BOOT" set biosboot=Boot/etfsboot.com set efiboot=efi/microsoft/boot/efisys.bin mkisofs -iso-level 4 -l -R -UDF -D -volid %label% -b %biosboot% -no-emul-boot -boot-load-size 8 -hide boot.catalog -eltorito-alt-boot -eltorito-platform efi -no-emul-boot -b %efiboot% -o %outputiso% %inputdir% This makes an ISO bootable both in legacy and UEFI scheme. mkisofs is not from the original version of cdrtools, but from reboot.pro: http://cdob.reboot.pro/ Exact executable I was using was this one: http://reboot.pro/index.php?app=core&module=attach§ion=attach&attach_id=15214 Please let me know in case you need chunks of the images (which ones & what length). Thanks, Ajgor.
LIGHTNING UK! Posted April 14, 2016 Posted April 14, 2016 Maybe you need to adjust the iso9660 restrictions / settings so it can use longer file names etc. Basically so it's the same as whatever ISO level 4 in mkisofs is.
LIGHTNING UK! Posted April 15, 2016 Posted April 15, 2016 The first megabyte of each image should be enough to examine things. If it isn't, I'll let you know.
ajgor Posted April 15, 2016 Author Posted April 15, 2016 I've uploaded the files on DropBox (settings screen shots and the first part of generated image): https://www.dropbox.com/sh/rlp21pk3ei5nb9t/AADx0j7SuxHH6tnPJ96mwFoua?dl=0
LIGHTNING UK! Posted April 15, 2016 Posted April 15, 2016 Can you also upload the same first chunk of the working ISO... Assuming the one on there now is the non working one? Oh and you should have pressed the 1999 button on the iso9660 restrictions tab. The Joliet restrictions don't apply as you aren't adding that one. I'd stick with udf 1.02 too.
ajgor Posted April 17, 2016 Author Posted April 17, 2016 I've taken the wrong screenshot before, Joilet instead of UDF restrictions. I've created UEFI ISO according to your instructions, still doesn't work. Files are here: https://www.dropbox.com/sh/wmp5qayy5lqmeyd/AAA1kEBvxq1Z0o9lq9TaBOgIa?dl=0 Included are the first megabyte of the original image (Gandalfs_Win8.1U1SE_x64_updateable_final.ISO.001), double boot image created by mkisofs (works; TEST_double_mkisofs_OK.001), legacy boot image created by ImgBurn (works; TEST_legacy_OK.ISO.001) and uefi boot image created by ImgBurn (doesn't work). File names tell what other files represent.
ajgor Posted April 17, 2016 Author Posted April 17, 2016 Update: I tried to create an ISO from USB, since this is what I've done when using mkisofs. The USB contents were created by Rufus from the same original ISO image used to generate the other images (Gandalfs_Win8.1U1SE_x64_updateable_final.ISO). I have uploaded the first bytes of generated ISO and the corresponding log file to the Dropbox directory with the above link. Result is similar (log file is more or less the same, it also doesn't work), just binary contents of ISO are different. List of files in the directory: Gandalfs_Win8.1U1SE_x64_updateable_final.ISO.001 - original ISO image (Win PE 8.1) from which other ISO images are created by ImgBurn. TEST_double_mkisofs_OK.001 - created by mkisofs from USB flash, which was created by Rufus from the original ISO image. It works both with UEFI and legacy boot. TEST_legacy_OK.ISO.001 - created by ImgBurn for legacy boot (log file: ImgBurn_legacy.log, screenshot: legacy_bootable.JPG) TEST_uefi_fromUSB_not_good.ISO.001 - created vy ImgBurn for UEFI boot from the original ISO image, does not work (log file: ImgBurn_uefi_not_good.log, screenshots: uefi_bootable.JPG, uefi_options.JPG, uefi_iso.JPG, uefi_udf.JPG). TEST_uefi_fromUSB_not_good.ISO.001 - created by ImGBurn from the USB flash (the same one as used to create TEST_double_mkisofs_OK.001). Log file: ImgBurn_uefi_fromUSB_not_good.log, the same screenshots apply as before (uefi_bootable.JPG, uefi_options.JPG, uefi_iso.JPG, uefi_udf.JPG), except that the source was different (J: instead of F:). Question: Under Advanced/Bootable Disc menu, how is the number of Sectors to Load determined in case of UEFI Platform ID, does it have any meaning?
LIGHTNING UK! Posted April 17, 2016 Posted April 17, 2016 It turns out that I need roughly the first 12000 sectors from the mkisofs image in order to look at the boot catalogue. That equates to 24,576,000 bytes. So 25MB will do it if that's possible please? Sorry, I don't know the answer to your question. It would probably depend on what it's meant to be for the file you're pointing it to as the boot image. Normally you'd get the information from a disc that works.
ajgor Posted April 17, 2016 Author Posted April 17, 2016 Hi, I've put around first 25 MB of TEST_double_mkisofs_OK.001 to the TEST_double_mkisofs_OK__split subdirectory, split into 19 files of 1.44 MB. I have a slow connection and it willl take some time for all files to be uploaded. I tried different things and I noticed that the original (Gandalfs_Win8.1U1SE_x64_updateable_final.ISO) is not UEFI bootable on VirtualBox VM, and also if I create new ISO images from the original bymkisofs (same parameters as described) they are only legacy bootable. As I mentioned, the double bootable ISO image that works was created by mkisofs from the double USB drive that was created from the original ISO image by Rufus, so obviously Rufus added the stuff that makes the USB (and ISO images created from it by mkisofs) UEFI bootable.
LIGHTNING UK! Posted April 17, 2016 Posted April 17, 2016 Ok, so what I need then is the image that's uefi bootable. I download the image you said you'd used as your source image... But if that in fact isn't uefi bootable, I guess I needn't have done so.
ajgor Posted April 17, 2016 Author Posted April 17, 2016 OK, that was a missunderstanding. So Gandalfs_Win8.1U1SE_x64_updateable_final.ISO, this was my original and is not UEFI bootable (didn't even check that), and I uploaded only the 1.44 MB part of it if you need to check anything. The mkisofs -generated image (TEST_double_mkisofs_OK.ISO) is UEFI bootable. It was created from original through USB stick (using Rufus) to the final version (using mkisofs), so: Gandalfs_Win8.1U1SE_x64_updateable_final.ISO ==> (by Rufus) UEFI bootable USB ==> (by mkisofs) UEFI bootable TEST_double_mkisofs_OK.ISO The first 25 MB or so of TEST_double_mkisofs_OK.ISO is in the TEST_double_mkisofs_OK__split subdirectory of posts_2 (split to 1.44 MB parts).
ajgor Posted April 17, 2016 Author Posted April 17, 2016 To further clarify, the problem is that I can create UEFI bootable ISO from UEFI bootable USB by using mkisofs (creating TEST_double_mkisofs_OK.ISO, which is both legacy and UEFI bootable) but I can not do this by using ImgBurn by suggested settings (the result is TEST_uefi_fromUSB_not_good.ISO, which is not UEFI bootable). With ImgBurn I could only create a legacy bootable ISO (TEST_legacy_OK.ISO), using settings from legacy_bootable.JPG in the uploaded directory posts_2.
LIGHTNING UK! Posted April 17, 2016 Posted April 17, 2016 Try 2880 for 'sectors to load'. If that still doesn't work, try disabling Unicode within the UDF file system.
LIGHTNING UK! Posted April 18, 2016 Posted April 18, 2016 Does it even look like its attempting to load anything from the disc? I don't have anything uefi capable but legacy bios boot sometimes shows error messages when something about the el Torito boot configuration isn't quite right. It's not supposed to be this difficult. It's just meant to look for the 0xEF platform id entry in the boot catalogue and boot accordingly (run the boot image it points to).
LIGHTNING UK! Posted April 18, 2016 Posted April 18, 2016 I just took an original Windows 8.1 image, mounted it in a virtual drive, pointed build mode at the virtual drive it and configured the 'bootable disc' tab with the UEFI platform, the efisys.bin boot image and set the 'sectors to load' to the value I gave you earlier (2880) and it's booted fine in VMware (set in EFI mode). I also created a legacy bios bootable version (so just changing the boot image to etfsboot.com, sectors to load to 8 and the platform id to 80x86) and that failed to boot in the EFI enabled VMware. Switch VMware out of EFI mode and the legacy one booted fine.
ajgor Posted April 18, 2016 Author Posted April 18, 2016 Does it even look like its attempting to load anything from the disc? I don't have anything uefi capable but legacy bios boot sometimes shows error messages when something about the el Torito boot configuration isn't quite right. It's not supposed to be this difficult. It's just meant to look for the 0xEF platform id entry in the boot catalogue and boot accordingly (run the boot image it points to). It seems that Windows boot manager is started, but the error displayed is strange, complaining about BCD file (efi/microsoft/boot/bcd). This is strange because the file is there, and it is precisely the same location and contents as the one contained on the original ISO image and the one contained in the mkisofs - created image that boots without errors on the same configuration (I boot form VirtualBox, have also used my laptob before). The error screen is in the file error_screen_boot_UEFI.JPG.
ajgor Posted April 18, 2016 Author Posted April 18, 2016 I just took an original Windows 8.1 image, mounted it in a virtual drive, pointed build mode at the virtual drive it and configured the 'bootable disc' tab with the UEFI platform, the efisys.bin boot image and set the 'sectors to load' to the value I gave you earlier (2880) and it's booted fine in VMware (set in EFI mode). I also created a legacy bios bootable version (so just changing the boot image to etfsboot.com, sectors to load to 8 and the platform id to 80x86) and that failed to boot in the EFI enabled VMware. Switch VMware out of EFI mode and the legacy one booted fine. Hmm... This would suggest either that the Windows 8.1 PE disk that I was using is different from the original Windows 8.1 in something that is important for booting, or that VirtualBox' implementation of UEFI is different from VMWare's. But I could easily boot form the ISO created ftom the same original via creating a bootable USB by Rufus and then creating ISO image by mkisofs. Also, in my previous testing, I could UEFI - boot those DVDs or USBs that I could also boot on VirtualBox on two actual systems (Acer Aspire V3 (quite old) and MS Surface Pro 4), and I couldn't boot those which I couldn't boot on VirtualBox. I haven't yet tried to boot the ISO image created with the latest settings (i.e. 2880 sectors to load) on actual systems (I will not have access for some time). I also cudn't boot any images created by ImgBurn with legacy settings when EFI was enabed, and all those images booted without any problems in legacy mode. Is it possible that VMware doesn't have a strict implementation of UEFI standard and is tolerant to some minor error in images created by ImgBurn? It would be nice to verify that on some other systems, but I will not have this possibility for some time.
LIGHTNING UK! Posted April 18, 2016 Posted April 18, 2016 I wouldn't expect any legacy images to boot in efi mode, they aren't supposed to. Each mode would look for entries in the el Torito boot catalog that they're meant to look for and ignore the others. Based on your last screenshot, I don't believe you issue is related to anything to do with the el Torito / bootable disc stuff at all. After all, it *has* booted, it's just falling over sometime after that. I will shortly be testing your source ISO in VMware to see if it boots in uefi mode before then rebuilding it with the same settings I used for the install disc and see how it goes.
LIGHTNING UK! Posted April 18, 2016 Posted April 18, 2016 Your untouched source image (Gandalfs Win8.1U1SE_x64 updateable final.iso) worked fine in EFI mode for me... as did the one I rebuilt in ImgBurn. They've both booted ok and gone right into Windows. I'm on the desktop screen as I type this.
ajgor Posted April 19, 2016 Author Posted April 19, 2016 Strange that the source image (Gandalfs Win8.1U1SE_x64 updateable final.iso) worked in EFI mode, on my VirtualBox it only worked in legacy mode, also on my laptop when I burnt it to a DVD. Like I said, I could only boot in UEFI mode the ISO that I created by mkisofs (TEST_double_mkisofs_OK.ISO). This one boots in both modes because it was created for both modes. The strange thing is that when I compare the Gandalfs Win8.1U1SE_x64 updateable final.iso (source image) and TEST_double_mkisofs_OK.ISO (created by mkisofs, bootable in UEFI), practically all files that could be related to booting and to the system, are the same, byte to byte and by paths within ISO. So if the original image really came to the point where Windows are started, how could it fail when the one created by mkisofs does not fail, and all Windows-related files are (in my opinion) exactly the same? As I understand, from the point when Windows begin to load, all data on disk is accessed through the file system paths and not through hardware addresses? This would then mean that if two disks have the same file structure, either Widows should run properly on both or should fail on both? The only differences in file systems between the source image and the mkisofs image are the following: mkisofs image has $RECYCLE.BIN, but this has nothing to do with booting or starting Windows mkisofs image has an additional directory (my customization), which has nothing to do with booting or starting Windows mkisofs image has a file boot.catalog (2048 , which is not contained in the source image. This could be the only reason in the file system for different behavior. boot.catalog was added by mkisofs when I created the image along the path Gandalfs_Win8.1U1SE_x64_updateable_final.ISO ==> (by Rufus) UEFI bootable USB ==> (by mkisofs) UEFI bootable TEST_double_mkisofs_OK.ISO The USB stick boots perfectly in UEFI mode although it doesn't have boot.catalog. Why is that, is boot.catalog specific to optical drives, or the reason for boot/not boot lies in lower level (not at the file system level)? When you booted the source image in UEFI mode, did you use the one I have upoloaded?
Recommended Posts