Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 

zamarac

Acronis ISO Boot on UEFI PC

Recommended Posts

Attached the small batch

 

Useful batch! :yes:   It works well for ATIH Linux based ISOs. Still "half-assed", since with ATIH WinPE based ISOs (and possibly with Linux based, where EFI.img is very small) it doesn't show size in sectors or bytes in a way that would allow ImDisk to mount the EFI.img. Instead the entire 500MB ISO or IMG must be mounted by ImDisk to view EFI.img content, and its unclear, how to extract the EFI.img. B)  You might consider downloading ATIH2015_WinE5.iso for the batch refinement - just follow safe download instructions. The file itself is CLEAN as reported.

 

dpk94m.jpg

 

Another issue is, while UltraISO is able to extract (ElTorito BIOS) Boot.bif from a mounted ATIH2014_Linux.iso (but not EFI.img), and then Save As it to Boot.img or extract content to a folder, it can't extract BIOS.bif  from a mounted ATIH2015_Linux.iso. Also ImDisk can't mount saved 2014 Boot.img - probably due to unknown offset. ISOBuster doesn't seem to show its BIOS.img content either. Not sure if it even exists, since mentioned Linux and WinPE ATIH 2015 ISOs were presumingly generated from UEFI Windows 8.1, but it should as they are made (according to Acronis KB) to be universally bootable on BIOS & UEFI systems. Is it possible to improve your batch in a way, so it can point to the BIOS.img as well?

 

ra81u0.jpg

 

 

The bigger question remains an unsolved mystery: How to boot the latest ATIH_WinPE.iso with Grub2

Edited by zamarac

Share this post


Link to post
Share on other sites

As said, the PE based .iso is likely to use an approach for EFI similar to the "standard" Windows 8/8.1 .iso's (which is a "1.44 Mb floppy image" even if the "type" is "No-emulation").

The posted batch was "targeted" to a "large" image only :blushing: my bad.

 

Find attached a modified version 0.02 of the batch that takes into account "small" images :yes:.

More technically it attempts to parse the "Large sectors" of the FAT image and if they are 0 it parses the "Small sectors".

 

If it is like that, i.e. there is a floppy image that contains a bootia32.efi or a bootx64.efi or a bootia64.efi in folder \efi\boot\, probably that is the file to be chainloaded :unsure:

 

On a "normal" Windows 8 install .iso, these files are also in the "normal" part of the CD/DVD, I believe that there are different kinds (how surprising :whistle:) of EFI/UEFI implementations, one, if you want more "strict", that looks for the "EF" image, and one that parses the UDF filesystem and finds the files in the "normal" part of the CD/DVD and these CD/DVD's are made in the attempt to cover all possibilties.

 

Also, the mentioned "dual mode" switches for OSCDIMG use a somewhat third approach, linking to the efisys.bin file "directly" (i.e. the \efi\microsoft\boot\efisys.bin is a "whole" image, a FAT 1.44 Mb floppy one, that contains the \efi\boot\*.efi and that can thus be chainloaded by GRUB2 as if it was the EFI image).

 

BUT I wouldn't be so sure :unsure: that the GRUB2 loopback approach does actually work chainloading a .efi file, see:

http://reboot.pro/topic/18313-grub2-iso-booting/

cdob surely will be able to comment more appropriately on this.

 

 

jaclaz

AcroCD_002.zip

Edited by jaclaz

Share this post


Link to post
Share on other sites

YES - now the batch works well for small and large EFI.img files! However, it still remains "quoter-assed", since while you were fixing it, the 2-nd problem shown up - it does show size and offset for EFI.img, but not for BIOS.img:whistle:

 

As to ATIH2015_WinPE5.iso, it indeed shows EFI folders in multiple places probably for "MS quality assurance" in addition to a small efisector boot EFI.img with one file:  \efi\boot\BOOTX64.EFI .

 

2i255op.jpg

 

24myohh.jpg
 

 

 

As said, the PE based .iso is likely to use an approach for EFI similar to the "standard" Windows 8/8.1 .iso's (which is a "1.44 Mb floppy image" even if the "type" is "No-emulation").

 

It would be nice, if that particular approach for booting it with Grub2 becomes known?     :P

Edited by zamarac

Share this post


Link to post
Share on other sites

I am not sure to understand what you mean by "BIOS.IMG" :unsure:

Do you mean the "no-emulation bootsector" or "no-emulation image"?

I.e. the one that in the screenshot you posted:

http://www.msfn.org/board/topic/172610-acronis-iso-boot-on-uefi-pc/#entry1085040

is 8 sectors in size and on LBA 186?

Or *something else*?

Can you post a more complete description of this "BIOS.IMG" or a screenshot of Isobuster or Ultraiso showing it?

 

The issue with GRUB2 booting a .efi file from a "loopback" device is - I believe - similar to the reason why Firadisk or Winvblock is needed for grub4dos booting Windows XP / PE's 1.x from .iso (and a ramdisk is needed also for Windows 7 install from .iso), at a certain point in the course of the booting process the grub4dos "real mode" hook is lost (unless another driver hooks it) and in the case of GRUB2 and loopback device, if the booted object is a Linux, the "real mode" loopback is "kept" by the Linux kernel (or whatever) but is lost because the Windows PE 3/4/5 misses a ramdiskl or filedisk driver hooking the loopback device.

 

jaclaz 

Share this post


Link to post
Share on other sites

I am not sure to understand what you mean by "BIOS.IMG" :unsure:

 

As mentioned here, each ATIH2014_Linux.iso contains 2 images: efi.img for booting on UEFI PC, and (eltorito)bios.img for booting on BIOS PC. While EFI Fat section is visible in ISOBuster under certain settings, bios.img AFAIK is NOT - neither in ISOBuster, no in UltraISO. However, the BIOS boot file can be extracted to bios.bif by UltraISO from the ISO mounted by ImDisk, while EFI boot file can be extracted in Windows either by ISOBuster (under Pro license), or via your free batch - thank you.

 

34iicz5.jpg

 

33adm44.jpg

 

Once the bios.bif is extracted, it can then be imported back to UltraISO, and reviewed or saved to bios.img or folder structure, but the bios.img is still not mountable via ImDisk (due to unknown offset?). That's why fully baked jaklaz's free batch ideally needs to point to two images (not one) or may be one bigger image comprising both?    :realmad:

 

28sn1fk.jpg

 

With ATIH2015_Linux.iso situation is a bit different: not only you can't see bios.img, but also UltraISO extracts instead what appears to be efi.bif or pointer file from the bootsector of Linux ISO mounted by ImDisk. Still its not mountable by ImDisk (due to unknown offset?) and neither importable back to UltraISO. I assume, its due to one of the reasons: 1) bios.img is absent in bootsector; 2) latest UltraISO is not yet capable to extract it. Nonetheless, the Linux ISO is expected to boot from both EFI and BIOS modes, so it likely needs 2 boot images?

 

ATIH2015_WinPE.iso also appears to have only one boot efi.img. But both Linux and WinPE5 based 2015 ISOs were tested to boot well in both BIOS and UEFI modes. Hence the question: how do they boot in BIOS mode?  Is it possible that both these images are in fact inside a single bigger ElTorito boot image (another ISO may be) hidden in a bootsector?   :o

Edited by zamarac

Share this post


Link to post
Share on other sites

The issue with GRUB2 booting a .efi file from a "loopback" device is - I believe - similar to the reason why Firadisk or Winvblock is needed for grub4dos booting Windows XP / PE's 1.x from .iso (and a ramdisk is needed also for Windows 7 install from .iso), at a certain point in the course of the booting process the grub4dos "real mode" hook is lost (unless another driver hooks it) and in the case of GRUB2 and loopback device, if the booted object is a Linux, the "real mode" loopback is "kept" by the Linux kernel (or whatever) but is lost because the Windows PE 3/4/5 misses a ramdiskl or filedisk driver hooking the loopback device.

Yes, it's possible to 'set root=loop' and 'chainloader /efi/boot/bootx64.efi'

This works: grub loads bootx64.efi.

However bootx64.efi dosn't detect the loopback device, there is no support. The booting is truncated.

Acronis Linux fails.

And WinPE fails too: \boot\bcd is not found

A UEFI wimboot may work in future http://forum.ipxe.org/showthread.php?tid=7261

Thanks for the awesome batch.

Nice to know: present a idea, relax and wait for a appropiate solution.

I call this teamwork. Good work.

 

 

It would be fine, if that particular approach for booting it with Grub2 becomes known?

Yes, that would be fine.

Neither Linux nor PE supports the loopback device.

As for today, I dare to say: there is no ISO file PE UEFI way.

Well, last ressort, follow the manufacturer approach: burn the ISO file to a real CD.

And use a hex editor to extract the boot images in doubt.

There is no GUI solution supporting all cases.

  • Upvote 1

Share this post


Link to post
Share on other sites

Neither Linux nor PE supports the loopback device.

As for today, I dare to say: there is no ISO file PE UEFI way.

Well, last ressort, follow the manufacturer approach: burn the ISO file to a real CD.

And use a hex editor to extract the boot images in doubt.

There is no GUI solution supporting all cases.

 

Is this glass half full or empty? In the past, such "no solution" statements prompted active development. As to using a hex editor - nah, after being offered such nice "teamwork" batch most users won't do that. It may be the only tool now available for migrating boot images, when transferring UEFI Acronis ISOs onto USB Thumb. Can't say I was very relaxed though, but you may be. That's why dat8.dat and dat9.dat dark secrets remain untold - I wonder, where that grub.cfg menu came from... probably from a hex editor...     :lol:

 

Isn't wimboot available today? I'm writing a half-assed Tutorial about it, then will follow it to try myself. But how it can affect ISO boot in UEFI mode - hasn't boot.wim been used to boot WinPE for a long while?     :angel

Edited by zamarac

Share this post


Link to post
Share on other sites

In the past, such "no solution" statements prompted active development.

Shure of course, there will be a solution.

Contrary it took several years to appear a ISO file windows driver.

Grub development rejeted El-Torito loopback in the past.

http://lists.gnu.org/archive/html/help-grub/2013-11/msg00013.html

http://lists.gnu.org/archive/html/help-grub/2013-11/msg00017.html

But it is not set in stone - try describing your use case on grub-devel.

https://lists.gnu.org/mailman/listinfo/grub-devel

Current linux distributions ueses hybrid ISO mode: a fake MBR partition refers to the CD.

It's possible to ISO hybrid the El Torito image. Asks the manufacturer to do this.

 

That's why dat8.dat and dat9.dat dark secrets remain untold - I wonder, where that grub.cfg menu came from... probably from a hex editor... :lol:

Actually, yes from a hex editor initially.

Didn't you extracted the image in between?

bootx64.efi is the acronis efi loader. And reads the configuration file bootx64.xml.

Can you open the file bootx64.xml? Read the file and convert to grub requirement.

 

Isn't wimboot available today?

This is another approach, complelwete different to the mentioned one.

Another manufacturer uses a previous existing name.

 

hadn't WinPE used boot.wim approach for a long while?

It's readable from the boot drive directly.

If you use single files, you may boot the Acronis boot.wim from from the boot media.

Share this post


Link to post
Share on other sites

I am starting to see. :)

 

As hinted before it seems like the good Acronis guys are NOT making a "standard" CD.  :ph34r:

 

UltraISO is reknown (to me at least ;)) to do some non-standard things as well (often, additionally not particularly well documented) :(.

 

In the 2012 iso image I have handy, the situation is as follows (and I believe the ones you have are not that much different).

 

There is actually a "hidden" volume image (FAT16, making use of the proprietary Acronis BOOTWIZ bootmanager bootsector) that extends from sector LBA 52 (2048 bytes sector) for an extent of 194397 sectors (in 512 bytes sector).

 

The actual Boot Catalog is on sector LBA 39 (and does NOT "index" this image).

 

Sectors LBA 40-51 contain binary data (possibly a loader of some kind, I'll have a look at it), which is the file that both UltraIso and Isobuster see as "Acronis.img".

 

The issue with a No-emulation entry in Boot Catalog is that it provides NOT the extension (size) of the image, but rather the number of Sectors to Load (usually 4, and that is the reason why originally the bextract.cmd batch was written http://reboot.pro/topic/12406-editing-iso-files/ ), all utilities will "see" (and incorrectly show as "size") only the "size to be loaded".

 

The first "next" LBA sector actually indexed in the Boot Catalog is the "next" entry (the EFI one) on LBA 48652.

 

What Ultraiso extracts as .bif is sized 187,869,184 bytes,i.e. 187,869,184/2048=91,733 (2048 bytes) sectors.

 

The actual .bif then comprises BOTH the "LARGE El-Torito No Emulation image"  i.e.  is the extents 40-48651 that are made of:

In 2048 bytes sectors:

Loader 12 sectors

FAT 16 image  194397/4= 48599.25 rounded to 48600

Some "mystery" sectors <-  :unsure: (need to double check)

AND the whole extents 48652-91773 of the "EFI" image (that UltraIso *somehow* does not "detect/highlight" properly in the sense of "separating it from the first", it exports the .bif containing "all it can find").

91773-40=91733 which is the size of the .bif, Q.E.D. :)

 

So, if you mount in IMDISK the .bif, once with image file offset 12*4=48 (512 bytes block) you get access to what you call "BIOS.IMG", while if you mount the same .bif with image offset (48652-40)*4=194448 (512 bytes block) you get access to the "EFI.IMG"

 

You will need to replace the 40 and 48652 in the above calculation with your values, and as well it is possible that the size of the loader is not in your .iso's 12 sectors, but once adapted it should work on your images as well.

 

It is still not clear at all (to me) how can UltraIso later "show" the contents of the .bif (which actually are the contents of the first FAT image, most probably it simply scans the file to find a recognizable BPB :unsure., I'll have to check with some dummy data.

 

About the little batch, if we put a "limit" (using common sense) to the possible size of the loader (let's say between 1 and 20 x 2048 bytes sectors) i.e. to the extents of the "search" for the bootsectors/BPB that needs to be performed, and we assume that the image is FAT formatted, it will be easy to find it and extract the corresponding sectors.

 

Still it has to be seen what the "mystery sectors" are related to. 

 

jaclaz

Share this post


Link to post
Share on other sites

It is still not clear at all (to me) how can UltraIso later "show" the contents of the .bif (which actually are the contents of the first FAT image, most probably it simply scans the file to find a recognizable BPB :unsure., I'll have to check with some dummy data.

 

 

Similarly, is it clear (to you), why UltraISO can show the content of ATIH2014_Linux.bif (what I call bios.img), but not the content of ATIH2015_Linux.bif (which is surprisingly only 2Kb in size compare to ATIH2014_Linux.bif at ~300Mb and ATIH2015_WinPE.bif at 4Kb)?   :)

 

And how these ISOs boot in BIOS - by using BOOTWIZ? I wonder why there is a need for 2 Acronis_Media structures in the 2014 ISOs that seem exactly the same, and why in 2015 Linux ISO the 1st Acronis_Media looks empty in UltraISO - may be it simply can't read its content?

 

Contrary it took several years to appear a ISO file windows driver.

 

Grub development rejeted El-Torito loopback in the past.

 

Are there any signs of someone even looking in that direction or to installing Win8.1 from ISO, as the problem seems to be similar? I'm a bit shocked to learn, once MS offered Win install from USB, no-one seems to ever bothered to adapt WinXP install from ISO approach to Win7/8 without extraction, despite it may be a very simple adaptation of WinVBlock (it started for 7 and died?) or FiraDisk.  :whistle:

 

And that is despite HUGE interest from the public... Our "Migrating Windows from BIOS HDD to UEFI VHD" thread on this forum was already read 800 times for the last 2 weeks - imaging, how many peeps will benefit from it for the next 6 months until Win9 comes in, and then?  :D Similarly, Acronis disks, whether we like it or not, are extremely popular, and huge number of folks would be happy to boot them from ISO on UEFI systems (which are now the ONLY new PCs available), or at least have some means to transfer to USB Stick without hard to comprehend known aggregate tools.  ;) That's were jaklaz's batch comes handy - if some clarity about ATIH.iso boot sequence in UEFI and BIOS modes is introduced as well.

 

Btw, in the interesting link you mentioned, the guy said to map El_Torito image and boot UEFI Linux ISO via ELILO, but not via Grub2. Is it possible to call ELILO from Grub2 to replicate that - may be its the way to boot more images with Grub2 via ELILO? How to install ELILO for that purpose?

 

 

But it is not set in stone - try describing your use case on grub-devel.

 

Its possible, though I doubt they didn't hear about Grub4DOS popularity and distinctions. Regarding Burg, which was called a "Windows friendly" Grub2 replacement, it was mentioned it has a different object model, but what was exactly different about it compare to Grub2? Might be its a serious obstacle in implementing image map support in Grub2? I guess Burg development stopped due to lack of interest in Linux dev community to support anything beyond Linux distros.

Edited by zamarac

Share this post


Link to post
Share on other sites

 

It is still not clear at all (to me) how can UltraIso later "show" the contents of the .bif (which actually are the contents of the first FAT image, most probably it simply scans the file to find a recognizable BPB :unsure., I'll have to check with some dummy data.

 

 

Similarly, is it clear (to you), why UltraISO can show the content of ATIH2014_Linux.bif (what I call bios.img), but not the content of ATIH2015_Linux.bif (which is surprisingly only 2Kb in size compare to ATIH2014_Linux.bif at ~300Mb and ATIH2015_WinPE.bif at 4Kb)? 

 

No, I have no idea, though most probably the WinPE version uses a "normal" no-emulation bootsector, 1, 2 or however a few sectors in size. (i.e. there is in it no "hidden image" at all.

The point is IMHO the other way round, i.e. how (the heck) it can access a .bif file which first sector is not a bootsector. :unsure:

 

Temporarily, try this modified batch (this is really @§§ed :w00t:, it will list on "normal" .iso's with a "small" no-emulation bootsector the EFI image twice).

 

Once the results are clearer, I may re-write the thingy with some more checks to avoid double detection (and possibly with some better structure).

 

jaclaz

AcroCD_003.zip

Share this post


Link to post
Share on other sites

Are there any signs of someone even looking in that direction or to installing Win8.1 from ISO, as the problem seems to be similar?

It's working in BIOS mode, with certain limitations.

I don't know any hint at UEFI mode.

As for wimboot: "wimboot DaRT70-x64.iso" loopback boot at BIOS mode

http://reboot.pro/topic/19970-grub2-wimboot-windows-setup/

There is efi wimboot. http://ipxe.org/wimboot http://git.ipxe.org/releases/wimboot/wimboot-latest.zip

How to adapt this to UEFI WinPE booting?

 

I'm a bit shocked to learn, once MS offered Win install from USB, no-one seems to ever bothered to adapt WinXP install from ISO approach to Win7/8 without extraction, despite it may be a very simple adaptation of WinVBlock (it started for 7 and died?) or FiraDisk.  :whistle:

Well, both drivers are at a higher level. Windows core boot files are running already.

The current issue is more basic:

Create a virtual disk: let windows loader find bcd, boot.sdi and boot.wim.

Share this post


Link to post
Share on other sites

this is really @§§ed :w00t:

 

It appears to be a step in right direction (with certain limitations).  B)  For ATIH2014 and 2015 Linux.iso it allows to create 2 images with ImDisk. It remains unclear however, whether the 1st image (equivalent to bios.bif) in fact is sufficient to boot the CD in BIOS mode. Any optimal way to verify that using a USB Flash or CD? As to the 2nd image (efi.img), its size is wrong resulting in mounting a CD instead of floppy.

 

ziqaz8.jpg

 

As to ATIH2015_WinPE5.iso, the batch identified twice the same EFI image, still causing questions about how BIOS mode boots?

 

2lac4rd.jpg

 

 

It's working in BIOS mode, with certain limitations.

 

Well, both drivers are at a higher level. Windows core boot files are running already.

The current issue is more basic:

Create a virtual disk: let windows loader find bcd, boot.sdi and boot.wim.

 

Can you give a link on how its working in BIOS mode for Win8.1 install from ISO? Also, can you look ones more at this post - there're some more interesting questions we may need to entertain.

 

As to the "issue been basic", may be someone let Sha0 know what's discussed here, and he might want to comment (or even suddenly offer the "basic" solution)?  :P

Edited by zamarac

Share this post


Link to post
Share on other sites

Hi,

 

jaclaz pointed me to this thread but I have now scanned through it twice and it's all a bit too much and over my head TBH. 

I do not use Linux btw.  and I am busy with other things as well and multi tasking is not my strength.

 

Can somebody put some clear points in front of me ?
Especially in where you feel IsoBuster fails or can be improved ?

 

As far as I can see from the screenshots IsoBuster shows the El Torito information, which *is* the way to boot from optical media.

Anything else is (as far as I know) not really optical and hence fancy stuff that is not really per the specifications (correct me if I'm wrong).

 

I tried to download the image (I think) but my virus scanner did not allow me to proceed, so I won't.

Is there an alternative download location ?

 

Do I understand correctly and is there a partition table in this image ?

Not very optical ? 

 

*.iso tells IsoBuster it's optical.  To explore it as a HD image for instance, forced, try renaming the file to *.dsk

Does this help ?

 

To find a hidden FAT file system, have you tried a scan for missing files and folders ?

 

PS. I think it's great that IsoBuster is used this way.  I developed it as an engineering tool for myself, that's how it all started.

Share this post


Link to post
Share on other sites

jaclaz pointed me to this thread. Can somebody put some clear points in front of me?

 

Which is great, hopefully he'll do the same for other relevant parties, and as well provide "clear points", what the problem seems to be with ISOBuster at exploring combo UEFI/BIOS Acronis ISOs. :yes:  You can download without issues the clean trial ISOs someone posted, just follow safe download suggestions

 

As to your questions:

 

- renaming the ISOs to DSK produces the same file structure in ISOBuster

- scan file system options are On by default, hence EFI Fat is visible. But the "other" image (extractable by UltraISO as .bif from bootsector of a mounted by ImDisk ISO ) is not, which you can test yourself by using jaclaz's batch jointly with ImDisk

- what do you mean under "shows El-Torito Information"? Which folder do you refer to on what screenshot? Is its content shown by ISOBuster sufficient to boot the ISO in BIOS and/or UEFI modes? if only in one mode, where is the "other" image?

 

2czpmpl.jpg

 

 

Thanks for the useful ISOBuster tool! This thread tells more folks about it.   :)

Edited by zamarac

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Recently Browsing   0 members

    No registered users viewing this page.

×