Windows 10 1703 won't boot on SANBOOT
-
Server
- FOG Version: 1.3.5
- OS: Ubuntu
Client
- Service Version: 0.11.11
- OS: Windows 10 1703
Description
I’m seeing an issue with the exit to hard drive after Windows 10 1703. We recently updatedto Windows 10 1703 in a lab, which were configured to boot to PXE by default. After the update, the computers sat at “Boot to SAN 0x80”. This wasn’t post-deploy. I could re-deploy a 1607 image and it would continue to boot just fine. I could also change the boot order or select booting directly from the HD without a problem.
I decided to take one of our test computers and create a fresh build with 1703 without going through the upgrade. I experienced the same trouble. After some troubleshooting I found that changing the exit type from SANBOOT to GRUB_FIRST_HDD seems to work ok.
It’s worth noting, though that the hardware on these didn’t change, only the Windows builds.##### Server
- FOG Version:
- OS:
Client
- Service Version:
- OS:
Description
Server
- FOG Version: 1.3.5
- OS: Ubuntu
Client
- Service Version: 0.11.11
- OS: Windows 10 1703
Hardware
Manufacturer: Dell
Model: OptiPlex 7040
BIOS: A01Description
I’m seeing an issue with the exit to hard drive after Windows 10 1703. We recently updatedto Windows 10 1703 in a lab, which were configured to boot to PXE by default. After the update, the computers sat at “Boot to SAN 0x80”. This wasn’t post-deploy. I could re-deploy a 1604 image and it would continue to boot just fine. I could also change the boot order or select booting directly from the HD without a problem.
I decided to take one of our test computers and create a fresh build with 1703 without going through the upgrade. I experienced the same trouble. After some troubleshooting I found that changing the exit type from SANBOOT to GRUB_FIRST_HDD seems to work ok.
It’s worth noting, though that the hardware on these didn’t change, only the Windows builds. I also realize this issue seems similar to https://forums.fogproject.org/topic/10386/windows-10-1703-system-error-on-boot, but I wanted to make the point that this wasn’t isolated to being part of the sysprepping process.
-
@crbarahona Thanks for pointing this out. Sounds like you thoroughly tested this. Do you think there is anything we can do from the FOG side? Should we inform the iPXE devs?
-
This post is deleted! -
@sebastian-roth I hadn’t thought through that iPXE development isn’t specifically related to FOG. I think it’d be worthwhile to inform.
-
@crbarahona Done: http://forum.ipxe.org/showthread.php?tid=10230
As well I am wondering if this could be an issue with installing as legacy/BIOS or UEFI. Were all installations/upgrades made as UEFI??
-
@crbarahona Is the OS configured as a Legacy (MBR) style image or is it configured as a UEFI style image? It, at least seems, to me to be Legacy style windows image as you are using the SANBOOT/GRUB_FIRST_HDD to work on both 1604 and 1703, but it almost sounds like 1703 is forcing some form of UEFI stack to the disk. (Maybe 1703 is changing the disk to a “dynamic” disk changing how the disk is partitioned without losing the data.) – (Doubt it as changing to GRUB works okay – then again GRUB is a proper bootloader and might not be hitting the constraints the bios is handing out as iPXE could be).
I really don’t want to think this is an iPXE issue considering the iPXE code did not change one bit. If it were an iPXE specific issue, the problem should be present on the same system regardless of what OS you deploy/use on it. The only variable that’s changed here is the OS on the client machine so it must be something that OS is doing.
The next question is more direct, I think.
If you deploy the 1604 image to a machine, boot into Windows, then deploy the 1703 image to the machine is this issue immediate? (When the machine reboots after the post deploy does it boot into windows or is it immediately broken?)
If it boots into windows 1703 and then fails on any subsequent reboots I would think there’s something Windows is doing regarding firmware which could be causing the problem. (It could even be something like the firmware to the NIC changing how iPXE is passing to SANBOOT, meaning iPXE might be able to do something to check and fix this.)
If it doesn’t boot immediately following deployment, then I believe the issue is how the disk is “laid” out.
I know there’s a lot of information here, just trying to get a full picture.
-
-
@crbarahona I tried with a windows 10 build 1703 install and it booted just fine. Still not sure where things go wrong here but as we seem to have several people with this we should be able to figure this out.
Please edit
/var/www/fog/service/ipxe/refind.conf. Changetimeoutto zero. Save this, change EFI exit type to rEFInd and boot the client. You should see a boot selection menu. Do you see it or does it hang even before that? -
I am marking this solved now as there hasn’t been any response and my guts say that this is not a general issue. Not with FOG and not in iPXE. Possibly this is a very specific hardware related issue but we won’t be able to fix this as there is not much information that we could work on.
