Jump to content

ajgor

Members
  • Content Count

    20
  • Joined

  • Last visited

About ajgor

  • Rank
    ISF Newbie

Profile Information

  • Location
    Luxembourg
  1. My reasoning about what causes the problem was obviously wrong. A simple explanation would be that bootmgr can not properly load the kernel because the BCD is corrupted or wrongly configured (error report states Error 0xc000000e, Windows failed to start. File: \EFI\Microsoft\Boot\BCD). However, the BCD was exactly the same on images that could not boot (the source Gandalfs Win8.1U1SE_x64 updateable final.iso) and on those that could (e.g. TEST_double_mkisofs_OK.ISO, which was created by the first one using Rufus and mkisofs). All files that could be related to booting and OS start were the same in both images, except the boot.catalog. But as as I understand, boot.catalog is not used after the bootmgr starts? When I finally created the ISO that booted normally by ImgBurn, it was with the UDF file system instead of ISO9660 + UDF. Everything looks the same when I compare this image with the one that fails to boot (created in the same way, except with ISO9660 + UDF). Files in the root and in directoies possibly involved in booting (boot, efi, bcdw, sources) are exactly the same, both images don't contain boot.catalog. Yet one boots well (the one with UDF) and with the other one, Windows boot manager reports Error 0xc000000e related to BCD. This looks mysterious to me, do you have any possible explanations?
  2. I also tried with UDF and - it works! Who would understand. For sectors to load I can not insert 0, but I can insert 1 and it works.
  3. Update: I tried to create an UEFI bootable ISO from the USB stick (containing contents of the source image Gandalfs Win8.1U1SE_x64 updateable final.iso transferred to USB by Rufus), but it did not boot in UEFI. I used the same settings as when creating UEFI ISO from the AOMEI backupper's image. Screenshots of settings are in the posts_3 directory. Strange, I really thought it would work now.
  4. OK, thanks. One interesting thing is if I created an UEFI bootable ISO by mkisofs form the USB stick, it worked. When I copied contents of the USB stick to a directory and created ISO image from that directory (using mkisofs with exactly the same parameters except the source), the ISO image was not UEFI bootable. Do you know what might be the reason for this?
  5. Oh my, this is getting frustrating... But I think I've made some progress. It seems that VirtalBox is somehow more strict about EFI than VMware. I can not boot on VirtualBox from the source image Gandalfs Win8.1U1SE_x64 updateable final.iso, no way. I played a bit more with mkisofs. Before I was running mkisofs on USB stick created from the source image by Rufus. This works fine, but when I try to just use the mounted source image or source image extracted to a a directory on hard disk, it does not work. It seems that Rufus adds something to the USB whet is necessary on VirtualBox to boot in EFI mode. I was then workinng on Windows 10 home official ISO (which boots to Windows installer) and on Windows PE ISOs created by AOMEI backupper as bootable media (rescue disks). AOMEI can generate a bootable disk based on Linux kernel or on Windows PE (the last one bootable either in BIOS or UEFI mode). This image is nice to play with because it is relatively small (below 300 MB). Both disks (Win 10 and AOMEI Win PE/UEFI) can be booted from VirtualBox. By mkisofs, I can create UEFI bootable image for VirtualBox from UEFI bootable ISO created by AOMEI Backupper. This can be done either from windows-mounted ISO image or from a directory where the image is extracted beforehand. If I also add files necessary for legacy boot (/bootmgr in addition to /bootmgr.efi and boot/etfsboot.com in addition to boot/efisys.bin) then I can create either bios, uefi or double bootable ISO. mkisofs always creates the boot.catalog file, but original UEFI bootable ISOS (Windows 10 Home and APMEI Win PE / UEFI) didn't contain that file. mkisofs can be run with paremeters -hide boot.catalog, but the file was still added to the ISO image. So, I tried to create an UEFI bootable ISO image by ImgBurn from AOMEI image and it was finally successful, I could UEFI-boot it on VirtualBox. I used the settings that you suggested (Restrictions & ISO9660 from 1999, Options/Include hidden, Include system files, UDF-Disable unicode, 2880 sectors to load). In mkisofs I can skip this argument (then it loads the whole image, which is default). Now, what concerns VirtualBox, it seems that when source image can not be booted in UEFI mode, the image generated from the mounted or extracted source image is also not UEFI bootable, either when creating the image with mkisofs or by ImgBurn. The source image Gandalfs Win8.1U1SE_x64 updateable final.iso could not be booted in UEFI on VirtalBox, but when I created a bootable USB from this image using Rufus, it could be booted in UEFI mode on VirtualBox. It seems that Rufus fixes something that is needed by VirtualBox to boot in UEFI mode, but was not included with the source image. Then, when creating a new image by mkisofs from that USB, everything was OK, but when creating it from the mounted or extracted original, the image did not boot in UEFI mode. I still have to try whether I can use ImgBurn to create an UEFI bootable ISO from the USB stick created by Rufus, now that I know which settings to apply.
  6. 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?
  7. 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.
  8. 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.
  9. I tried, it still doesn't work.
  10. 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.
  11. 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).
  12. 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.
  13. 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?
  14. 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.
×

Important Information

By using this site, you agree to our Terms of Use.