FOG triggering Windows 10 Automatic Repair
-
@ldiorio The question in my mind is it the fact that you have CSM disabled causing the auto repair or something refind is doing?
To test this you could change the refind timeout (in /var/www/html/fog/service/ipxe/refind.conf) to something like 20 seconds. While waiting in the refind time out, power off the computer. Then power it back on. See if its refind for sure causing the issue or because CSM (legacy roms) are disabled.
-
This post is deleted! -
@george1421 Alright so I just did the test. CSM disabled and powered off the machine during the refind pause. Booted to windows and it booted up normally.
-
@ldiorio ok good, then its not something that FOG is doing to the image. Can you try one more test, do a warm restart. At the refind pause press ctrl-alt-del and see if it reboots correctly after imaging…
Wait, I think I lost where we were. This isn’t after imaging but just booting through the iPXE menu. So every time you boot through iPXE refind triggers a disk recovery? Do I understand that correctly? This has nothing to do with imaging at all.
-
@george1421 correct this is happening when simply booting through the ipxe menu with refind. The default exit setting (refind) is being used since all other exit options were causing a loop at the ipxe menu. Also the warm restart resulted in windows booting correctly as well.
-
@ldiorio As a test, can you grab refind from here: https://sourceforge.net/projects/refind/files/0.11.2/ (grab the zip file) and extract refind.exe and move that into the fog/service/ipxe directory (renaming the original one). The version of refind on FOG 1.4.4 is older. I want to see if the newer version manages the exit better.
-
@george1421 Alright so I did the test with 0.11.2, same issue…BUT you gave me the idea of using the refind binary and conf file from the master FOG branch rather than the latest dev…works perfectly.
-
@ldiorio Really, older is better? I’m glad you have it working, but a bit surprised with the results. I’ll take this info back to the devs to see if this is just a one off issue or there is an issue with the updated version of refind, since refind is an external package included with FOG.
-
@ldiorio Very interesting, thanks for testing and sharing this information. I think it’s worth to get in contact with the rEFInd developer to make him aware of the newer version having an issue in that case.
@george1421 As we only use the binaries provided I don’t see what we could have done wrong here with the newer version.
-
@george1421 Alright, just as a note I did some further testing by mixing different refind binaries and conf files. It seems something from the conf file in the dev branch is whats causing the issue because I was able to boot properly by using the master branch conf regardless of the refind binary being used.
-
@ldiorio Very interesting. Have you run a diff between the two config files to see what was changed? Its good you found this issue before FOG 1.5.0 (stable) is released.
-
@george1421 I did, one of the first issues I had (and this was before I even started having a problem with Windows booting) was in the new conf the ‘scanfor internal’ option was changed to ‘scanfor internal,hdbios’ which caused refind to look for BIOS boot loaders as well. That caused an immediate interrupt on my systems because they are all EFI with CSM disabled. I manually changed that line to get rEFInd to work properly, and it was at that point that I ran into the issues with Windows.
So I did more testing with the conf files now, and it seems that the scan delay is whats causing the issue. I downloaded a fresh copy of the refind binary and conf from the FOG dev-branch and made the scanfor line change as well as commented out the ‘scan_delay 5’ line. As of now, the configuration is working.
-
@ldiorio Interesting the scan delay setting was added intentionally to give the uefi firmware a chance to fully boot up before attempting to exit via refind. We may need to reconsider switching that back if it continues to cause an issue. It was turned on by default to solve a problem, but then it appears to have caused another.
Thank you for all of your fine detective work on this. Without the actual hardware in our hands, it hard to debug issues like this.
-
Cross link: https://forums.fogproject.org/topic/11522/fog-1-5-fresh-windows-10-pro-can-t-go-past-pxe-menu
So we don’t forget about this…
-
I had a similar issue, but (dumb) lucked into a solution.
Dell Optiplex 3040, BIOS set for UEFI: Onboard NIC (IPv4) first, Windows Boot Manager second.
Installed Win10 Enterprise from USB. After the install and first time on the desktop, before installing anything else, a reboot would come out of the UEFI network boot with Preparing for Automatic Repair. (I gave it plenty of time — about 14 hours! — never got past that screen.) I installed again and got the same results.
I made one change in the BIOS: added a check to ‘Enable Attempt Legacy Boot’ and then installed again. This time, at the first reboot, the screen went dark and … nothing. Manually powered off and back on and was able to log into Windows. But the next reboot, again the screen went dark and stayed that way. So I removed the check from ‘Enable Attempt Legacy Boot’ and now Win10 is working fine, normal reboots, exiting from the UEFI network boot into Windows.
Hope that might be helpful to someone.
