Skip to main content

True Image not starting on media created from wim file

Thread needs solution
Beginner
Posts: 1
Comments: 2

Dear all,

I used the bootable media wizard (using options: advanced, win pe based, windows 8, 8.1 and 10 (ADK option)) to create a wim file . As a reduced test case I then only tried to create a bootable image file from the wim file (without further modifications) as follows:

copype amd64 C:\WinPE_amd64

Dism /Mount-Image /ImageFile:"C:\ATI\AcronisBootablePEMedia.wim" /index:1 /MountDir:"C:\WinPE_amd64\mount" 

Dism /Unmount-Image /MountDir:"C:\WinPE_amd64\mount" /commit

MakeWinPEMedia /iso C:\winpe_amd64 "C:\ATI\pe_vm.iso"

The created pe_vm.iso boots fine into the recovery environment, however Acronis True Image is not started.

I am on Windows 10 and using the latest True Image 2019.

Any hint on this? Thanks!

0 Users found this helpful
Legend
Posts: 46
Comments: 15506

welcome to these public User Forums.

Please consider using the MVP Custom ATI PE Builder tool rather than doing this manually, this will create both an ISO and WIM file plus can create a boot CD/DVD or USB stick.  Link in my signature below.

Forum Star
Posts: 42
Comments: 1453

There's no need for your mount and unmount commands. In place of them use:

del C:\winpe_amd64\media\sources\boot.wim

copy C:\ATI\AcronisBootablePEMedia.wim C:\winpe_amd64\media\sources\boot.wim

 

Forum Hero
Posts: 46
Comments: 7040

no idea

I suppose, the question is why Acronis isn't booting at all in the existing .iso?  How long did you wait?  If you let it sit for say, 5 minutes, does it eventually come up... there have been users in the forums that had similar behavior and it just took some waiting for it to come up. 

I tend to only use USB flash drives these days and it is usually pretty fast.  CD's can be unreliable (defect from the manufacturer, too many writes if RW, break down over time if stored for awhile, bad write to disc, etc.) and they're just plain slow in most cases.  

It sounds like you're just trying to use the same .wim file but build a new .iso with it using ADK DISM commands as a test.  FYI, this is where using a USB thumb drive can be really helpful too.  You can just delete the existing boot.wim and copy in another one in it's place 99% of the time, instead of having to build new .iso's with DISM.

 

 

Beginner
Posts: 1
Comments: 2

First, thank you all!  Mustang's post did the trick. I wasn't aware that only the boot.wim is put the on iso, I expected the content of the mount directory to be placed at the iso, but that's not the case.

Forum Hero
Posts: 46
Comments: 7040

Sweet.

Yup, the mount directory in winpe becomes boot.wim. you can easily view the contents of the boot.wim with the free tool 7zip.

Beginner
Posts: 1
Comments: 2

Bobbo_3C0X1 wrote:

Sweet.

Yup, the mount directory in winpe becomes boot.wim. 

no, that's exactly the mistake I made. The mount directory content is written back to the wim file that was mounted into the mount directory. However the MakeWinPEMedia always uses the boot.wim in media/sources. And if one didn't mount this boot.wim in the mount directory, then the issues I had happens ;-) 

Forum Hero
Posts: 46
Comments: 7040

I see what you mean.  What I referred to is that the working directory of the media builder ends up becoming boot.wim on your rescue media (iso, usb flash drive, burned disc).  The MVP tool essentially copies the default winpe.wim from ADK (C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\en-us) into it's own temp directory, mounts it and then injects what it needs to so that the original winpe.wim is never touched or modified and available for other programs to use as needed without interfering with it.

Mustang's command above allows you to mount the specific boot.wim from the mvp media, instead of the default ADK winpe.wim which is extracted to C:\winpe_amd64\media\sources\boot.wim when you used the initial command of copype amd64 C:\WinPE_amd64.

We meant the same thing, just thinking about it differently based upon how we use ADK locally.