Surface Pro 7
-
Hello,
So the FOG server is working great for 95% of our machines. we have a handful of Surface pro 7s that need to be imaged. I have successfully captured an image of a device that needed to go out for warrenty repairs. Upon receiving it back it was factory reset ( surprise surprise) so I scheduled a deploy of the image and this is the result:
-
@epsilon52 The quick answer is the certificate used for apache (HTTP) is not the same certificate used when ipxe.efi was compiled.
How did you enable the https service in the web server? Did you run the fog installer script with the -S option to enable https in FOG?
-
@george1421 Honestly its been so long since i installed the server i dont remember. im 90% sure I enabled https in the GUI install. Do I just need to recompile the ipxe.efi? We did just do a domain shift so it is possible someone changed the certificate.
-
@epsilon52 domain shift in DNS domain or windows domain? If your DNS names are different that may have an impact on FOG.
Either way the error is that the certificates for ipxe (ipxe.efi and undionly.kpxe) don’t currently match what apache is running as.
I don’t know if you can fix it by rerunning the installer with the -S switch or not. I have not personally worked with FOG and SSL.
-
@george1421 we switched domains from a .local to a .net so that probably did it. Do i need to delete the old ipxe.efi file before rerunning the script?
-
@epsilon52 The installer should replace all of the ipxe boot files when it recompiles the boot loaders. Its all of the ipxe files not just the two I mentioned.
-
@george1421 That did not work… It ran and everything when I ran ./install foginstaller.sh -S but it still is giving the permission denied error above on the host.
-
@george1421 Here is a interesting plot twist. On another machine it runs just fine. I am able to capture and deploy. it is something with the surface pro 7. Secure boot is off cause i know that will be a question.
-
@epsilon52 Is the ipxe build version the same number between the working system and not working system. In the OP the build number is g3475f confirm that you are using the same build number between working and not.
-
@george1421 It is different! 1.21.1 Gc42f. why would that happen? thats very odd. … EDIT: no I just reran the OP machine too now it is the same and still erroring out.
-
@epsilon52 We that is interesting why they would be different then not. I know at one time we suggest that people use an old boot loader with the surface systems because (at the time) the updated ipxe boot loaders were crashing on the surface devices. The version check was to see if there is a different ipxe boot loader coming into play between the working and not working target computers.
-
@Epsilon52 @george1421 At first I though DNS change might be an issue here but looking at the picture again I am fairly sure there is an IP not a hostname used. So DNS should not be it.
The versions we see (first (g)3475f and then (g)c42f) tell us that the re-compilation worked fine I’d say - the match up with the iPXE commit IDs from Dec 9, 2020 and now latest from Jan 4, 2021.
But it seems very strange that you only get this error on the surface. Do you remember when you booted a surface last and it worked? You can go back to older iPXE versions if you know a commit ID that worked…
-
@sebastian-roth @george1421 So after going into DHCP i changed my bootfile undionly just to see, then it didn’t work I switched back to ipxe.efi and it worked just fine. i had a thought that somehow it just got hung and by removing and re-adding the bootfile seemed to fix the issue. I suppose we can catagorize this one as a “Huh… well okay” sort of thing.
-
@Epsilon52 Thanks for the update and good to know. Maybe it just needed a cold boot or something like that.
