ACPHO update 40729 rescue media error
Yes, you'll need to do step 3 again if your project has the AUR.wim as the sources.
Mustang wrote:Now let's talk about the disks in your computer. You seem to have 3 Windows system disks. One with Windows 7 and two with Windows 10. Are you booting from all of these disks? If so, how do you do it? Do you enter the BIOS and select the disk you want to boot from? What type of disks are they (HDD, SSD, NVMe)? These are a lot of question, but there're all important.
Booting Windows 7 and Windows 10 systems that are able to see each other and the same data disks is dangerous. How often do you see your drives need to be scanned for errors? Do you run into permissions problem on your disks?
I take it your motherboard isn't very new. Modern motherboards don't like seeing multiple Windows systems. The BIOS can start to make changes to the BCD boot files and cause systems to fail to boot.
I used to have multiple systems in a single computer, but have stopped that practice. I now have my Windows systems on that computer on 2.5" SSD's. This allows me to use a swappable drive tray system so I can select which system to boot by swapping the disks. I don't use M.2 NVMe disks on this computer because they are to hard to swap.
About My Disks
I have 3 legacy windows 10 system disks from the migration
Offered by Microsoft from Windows 7 to Windows 10
My main drive is a corsair MP510 240 GB NVMe
My other two system drives are samsung 256GB SSDs
The choice of one or the other of the systems is made
by pressing an F11 button during start-up which displays the different starting options
My motherboard is a MAG X570 TOMAHAWK WIFI (09/2020)
I am the only user of this PC and make backups (acronis since 2016) before any risky operation
No permissions issues and the latest search
error (which turned out to be negative) was made following a post by 'enchantech' on this Forum.
To conclude I don't use this PC for professional purposes, but rather as an indispensable tool, a source of leisure (photography, music.. ) and intellectual activity (computer science, where I started at UNIVAC a few years ago...)
Your previous post
I also wanted to go back to your previous post
I followed your recommendations and achieved a completely positive result on the first try
Thank you again for the clarity of your explanations
I think it will be necessary for me to apply paragraph 3 of your explanations to the creation of a new AUR project with ACPHO, isn't it ?
I understand what you're doing with your computer. If I were you I would transfer the main system off the NVMe drive to another Samsung 256 GB SSD. Then get a tray-less hot swap unit that fits in a 3.5" bay to boot your systems conveniently one at a time.
Alemax,
It is good to know that you seem to have overcome the issues surrounding your WinRE version on your system.
With regard to your use of OS disks in your machine, I must side with Mustang here on that. I have adopted the same policy as he has in utilizing a trayless 3.5 inch drive caddy to house OS disks of varying installs. UEFI booted machines store boot information in firmware on current PC motherboards. This works however, that boot information can become corrupted and can lead to a number of issues with further data corruption all of which is not good.
The F11 key boot menu you mention is referred to as a one-time boot menu. Since I have moved to a single OS drive attached at any given time setup my one-time boot menu will only show that drive. The only exception to that is when I attach a removable flash drive to the system which will show up in that menu. Since default boot is always to an internal drive source I can have confidence that data corruption will not occur due to having multiple internal OS disks attached at one time.
Mustang wrote:I understand what you're doing with your computer. If I were you I would transfer the main system off the NVMe drive to another Samsung 256 GB SSD. Then get a tray-less hot swap unit that fits in a 3.5" bay to boot your systems conveniently one at a time.
I agree with you regarding the NVMe Drive, access is complicated.
Regarding access to a 3.5 bay it is very complicated with the configuration of my office.
If it is easy for me to disconnect a SATA cable, when I need to access the bays, I take my PC under my arm
and accesses a large space (unheated) where I can carry out complete assembly / disassembly
For the rest I carried out a few tests
I tried reconnecting one of my SSDs to clean up the information that was causing the Winre.Wim errors
this information was in
E:$WinREAgent
Cleaning
I booted on SSD SYS_2
Via Explorer on C: Properties > Disk Cleanup > Clean up system files
I also checked windows update cleaning
I then deleted the $WinREagent folder
I then rebooted from my system disk SYS_1-M2
I renamed L:RecoveryWindowsRE to XWinre.wim (your procedure) to test the creation of AUR.Wim which is in error again
I disconnected SSD SYS_2 again to check from SYS_1-M2 the creation of AUR.wim which took place without error
I (once again !) reconnected the SYS_2 SSD to search for Winre.wim, but this time the search gave no results
and I don't see where to look (Register?)
Just one info about my 3 system disk : all MBR, I do not use UEFI (post from enchantech)
Enchantech wrote:Alemax,
It is good to know that you seem to have overcome the issues surrounding your WinRE version on your system.
Almost, only is disconnect 2 SSD System disk ,
With regard to your use of OS disks in your machine, I must side with Mustang here on that. I have adopted the same policy as he has in utilizing a trayless 3.5 inch drive caddy to house OS disks of varying installs.
I answered to mustang
UEFI booted machines store boot information in firmware on current PC motherboards. This works however, that boot information can become corrupted and can lead to a number of issues with further data corruption all of which is not good.
All my 3 systems are MBR, not UEFI
The F11 key boot menu you mention is referred to as a one-time boot menu.
Since I have moved to a single OS drive attached at any given time setup my one-time boot menu will only show that drive.
Yes if you have only one system , in my case i can choose the one to boot
The only exception to that is when I attach a removable flash drive to the system which will show up in that menu. Since default boot is always to an internal drive source I can have confidence that data corruption will not occur due to having multiple internal OS disks attached at one time.
I searched and I think I finally found a solution that allows me to prevent the media builder from finding the Winre.wim inherited from Windows 7
Before creating Acronis Universal restore with diskpart, I make partition 1 of each of my other system disks SYS_2 and SYS3 INACTIVE
I carried out the test on SYS_3, I inactivated its system reserved partition, and I started the creation of AUR
I finally recovered a correct AUR.WimI then reactivated partition 1 of disk SYS_3
There may be a risk of deactivating the system reserved partition in this case (deactivating the partition of the running system)
I think however that it should be possible to adapt a script to inactivate (then reactivate) the 2 discs 'not running systems'
There is a way to force Acronis to use the correct winre.wim without disconnecting drives or modifying your systems. You can select the option in the AUR media builder to "Use WinPE files located in the folder I specify". Follow the steps below:
1. Use MVPAssistant and create a new project. I named it Test. Select WinRE as the source. After the image is acquired, go to Windows Files Manager and navigate to the Test\Media project folder. Create a folder named sources under the Media folder.
2. Copy Test\Wim\winre.wim to the new sources folder and rename it boot.wim.
3. Under the Test folder create a new folder named fwfiles. This will show up above the Log folder.
4. You will need to copy two Windows files to the fwfiles folder. The first is named efisys.bin and is found at C:\Windows\Boot\DVD\EFI\en-us. The second is named etfsboot.com and is found at C:\Windows\Boot\DVD\PCAT.
5. Now run the AUR media builder and select the "Use WinPE files located in the folder I specify" option and click the Next button. Select your language and click the Next button. You will now need to point to the correct folder. There is only one folder that will work. That folder is Test\Media. Click the Next button and you should see the Add Drivers screen. The rest of the build process is the same as you've always done. Create the media as an ISO file. That can be used as the source for an MVPAssistant project to add ACPHO.
6. After the media is sucessfully created go back to MVPAssistant and open the Test project. Now choose Project/Erase Project.
That should give you the AUR media based on the correct winre.wim.
Flawless !
To apply the solution I tried it twice following a distraction on my part
Everything then went as planned except that I had not included the corrections that you had communicated to me concerning snapapi.dll and snapman.sys.
So I applied the fixes and rebooted from the USB stick
all is correct
I would just have to go over the different informations that was given to me (because it is a little scattered on my side)
Thanks again for your help
I'm glad to hear it all worked for you. Sorry I forgot to mention about the snapapi fix.
Alemax, the new version 2.7.5 of the MVP Assistant fixes the snapapi issue so you should no longer have to worry about fixing that manually.
BrunoC wrote:Alemax, the new version 2.7.5 of the MVP Assistant fixes the snapapi issue so you should no longer have to worry about fixing that manually.
Thanks
That's a good news, i 'll download the new version ASAP
I installed MVP version 2-7-5-1 and ran some tests
I followed the solution (§ 1 to 6) from 'Mustang' posted on 2023/10/19
and managed to create a bootable key from the ISO file created by the AUR build media.
2 comments
§ 5 The driver update window (CMD) only appears after choosing the .ISO destination of the AUR built media
§ 6 Now choose Project/Erase Project.
if you erase project test you will loose the Rescue builds\Test\Media\RecoveryMedia.iso
you should backup before in another place
Aside from this, the SNAPAPI problem is corrected
Thanks you all
Alemax, glad to hear things are working better on this issue.
A couple small comments...
I you are using the AUR wiim as the source for an MVP Assistant rescue media project, you could forget about the AUR driver interjection and just do that later from the MVP Assistant builder.
If you erase a project which has an ISO saved within the project folder, you should get a second query asking if you want to keep the ISO or erase it too. You won't lose the ISO unless you specifically permit it.
BrunoC wrote:Alemax, glad to hear things are working better on this issue.
A couple small comments...
I you are using the AUR wim as the source for an MVP Assistant rescue media project, you could forget about the AUR driver interjection and just do that later from the MVP Assistant builder.
- I carried out the test, but if the test project was Erased (§6 of the resolution) the Wim folder and the winre.wim file are also lost.
If you erase a project which has an ISO saved within the project folder, you should get a second query asking if you want to keep the ISO or erase it too. You won't lose the ISO unless you specifically permit it.
- I carried out the test, erased the Test project, but did not get any message about the ISO.
In the Rescue builds Test folder only the fwfiles folder and its two files efisys.bin and etfsboot.com (created according to § 4 ) remain.
No more ISO file or media folder
Alemax, my first comment about driver insertion was intended to be done when creating the media using the MVP Assistant... at the end of step 5, before erasing the project. If you create an ISO from the MVP Assistant, it wants to put it into the ISO folder under the project and that folder will not be erased without permission. The other fwfile folder will not be erased because the MVP Assistant does not "own" it.
Erasing the project is not a requirement.