• Good afternoon!

    I’m trying to image 10 Surface Go’s, hopefully with my existing UEFI image.

    I’m using a Microsoft Surface Dock, I’ve configured the BIOS to make sure I can boot to the dock, I’m able to boot to FOG and get to the menu. When I try to register the Surface with FOG, I get this error:


    Not exactly sure what all this means (other than something isn’t working).

    If I try to skip the registration, and just push the image, FOG tries, but it seems to hang forever at erasing the current MBR/GPT table and never goes further.

    10 isn’t a huge number, and I can do these by hand if needed, but I have a feeling I’m going to see a lot more of these Surfaces soon, so any help or suggestions would be appreciated.


  • Moderator

    @Minxster @Vanlue-IT-Guy Have you search the forums yet? There have been many discussions on various Surface devices (2, 3 and 4) where some seem to have very similar issues. Here is an interesting one you might want to read from start to end: https://forums.fogproject.org/topic/11635/microsoft-surface-pro-4-using-dock-has-issues-with-dhcp-for-imaging-task

  • @Sebastian-Roth Thanks for this… I think I’ll start a new thread, I can then spell out whats happening with images :-).

    I’m happy to go down the compiling route as long as I can follow it 🙂 But I’ll be back in-touch if I’m stuck, but hopefully I can come back with some conclusions and/or some feedback on what to try next?

  • @george1421 Thanks for that… We’ll get straight on an double check the UEFI version and make sure it’s the latest!.. I did see mention of using boot devices with bzimage+inits, I think I’ll try this last as it would be great to help and an diagnose this. 🙂

  • Moderator

    @Minxster said in Surface Go Imaging:

    Is there anything I can do to help speed up diagnostics? How do I drop to a console window on the client computer to help run commands?

    To speed up diagnostics you’d best get into compiling the Linux kernel with added debug information. It’s really not that hard when you follow the instrcutions in the wiki. We’ll help you pinning down where exactly it hangs.

    You might wander why you need to do that and it’s as simple as “we don’t have the hardware to test”. So we need you to do it.

    Hi, we’re in the exact same situation here.

    From what I read in your post you seem to have a different issue than what the initial post was about. Feel free to open a complete new topic and post your own information. FOG version, picture of the problem, …

  • Moderator

    @Minxster This is typically an indication of a buggy uefi firmware. I suggest that you update your firmware to the latest release for your hardware. If we can’t seem to get by the iPXE hand off to bzImage there is another route that contains several caveats. But its better than nothing. The idea is to build FOS (bzImage+inits) onto a usb flash drive and to boot from that. I have a tutorial on how to do this here: https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image

    Read through the entire article before you start. Make sure you understand the caveats of going this route since iPXE is not involved there are a few. The Mac users have to go this route to get their systems to boot into fog.

    (PS: Look at the forum chat bubble [upper right corner of the browser window] for a few more hits)

  • Hi, we’re in the exact same situation here. We’ve got a number of Surface Go’s that just refuse to get beyond the bzimage/init.xz.

    The dock we’re using is for the Surface Go. The initial PXE boot seems to work, we’re using ipxe.efi just now. But it just seems like the NIC is dead in the dock even thought it initially started to boot.

    We’re using the latest version of FOG, along with the latest kernel and I just updated the init.xz (and init_32.xz) that george1421 mentioned below.

    Is there anything I can do to help speed up diagnostics? How do I drop to a console window on the client computer to help run commands?

  • @Sebastian-Roth I managed to cause a different issue troubleshooting, and had to rollback then update my server. I’ll probably make a separate thread later. Thank you though!

  • Moderator

    @Aysientor In most cases the “exact same issue” is still a bit different. Please provide your own information here. Screenshot of the exact error you see and you might want to check the apache and PHP logs as I suggested to the other poster months ago.

  • Not sure if I should make a new post for this, but i’m having this exact same issue trying to image Surface Gos (currently running FOG, and am able to image any other PC).

    I was wondering if the ever got resolved?

  • @Tom-Elliott

    Our DHCP is done by Windows Server. Interestingly, other machines can get to FOG, and I can image them, but not the surfaces.

  • Moderator

    @Vanlue-IT-Guy said in Surface Go Imaging:

    Here is the picture you requested:

    As I guessed, different error. It’s kind of strange that the Surfaces seem to hang at different stages. Mostly seems related to not being able to access the FOG web server. You might want to check the apache error logs (see my signature) as suggested earlier! Possibly it’s just a lot of clients in your network causing random failures?!?

  • @Vanlue-IT-Guy So the IP address your machine is getting is, the IP address of your FOG server is

    As far as I can tell, you have a Class B network setup? (Subnet of What’s handing out your DHCP information? Based on what I can tell, the machine simply cannot reach the FOG Server after it gets its IP information.

  • @Sebastian-Roth

    Here is the picture you requested:


    Hope it helps!

  • Moderator

    @Vanlue-IT-Guy said in Surface Go Imaging:

    I’m unable to run a compatibility test, as I get a similar error.

    Please take a picture and post here again. I am sure the error is different and might sched a light on what’s wrong.

    As well please run the curl command as suggested earlier: curl -Lks --data "mac=aa:bb:cc:dd:ee:ff" and if you don’t have a linux command shell available you can at least open the URL in your web browser on the client to see if that returns an error. As well check apache error log…

  • Moderator

    @Vanlue-IT-Guy Don’t worry about the version and saying you are out of date. As long as you have the right version you have the fixes the developers have created for 1.5.4 for FOS. There are a few fixes in the webgui that you don’t have, but your issues right now is with FOS running on the target computer.

    Ok now that you have the latest fixes, are you still running into an issue when you run hardware compatibility?

  • @george1421

    OK. I’ve done all that, both the kernels and the inits. I noticed I’m running of FOG. It says I’m out of date. Not sure how to update that either.

  • Moderator

    @Vanlue-IT-Guy The fog/fos kernels can be updated via the fog settings->kernel update menu. The inits are a bit harder but possible.

    If your fog server has internet access you can do the following

    cd /var/www/html/fog/service/ipxe
    mv init.xz init.xz.sav
    mv init_32.xz init_32.xz.sav
    wget https://fogproject.org/inits/init.xz
    wget https://fogproject.org/inits/init_32.xz

    That coupled with the kernel update will fix a few issues (probably not THIS issue) but its good to get to a known configuration.

    You should follow Sebastian’s guidance to debug the issue making the curl call.

  • @george1421

    I’m unable to run a compatibility test, as I get a similar error.

    I’m running FOG 1.5.4 on CentOS. Installed it fresh back in July.

    I used to run FOG on Ubuntu and knew the proper steps to update it through that, can you share the right commands in CentOS to update FOG?

  • Moderator

    @Vanlue-IT-Guy What happens at this stage is the client sends a HTTP request to the FOG server to check if there is a client registered with the same MAC address already. I know the error message should be more precise here. Going to change that…

    This failing means there is something wrong with the PHP script called on the web server. Try the following CURL HTTP query on a command shell: curl -Lks --data "mac=aa:bb:cc:dd:ee:ff" (while putting in the client’s correct MAC address instead)

    As well check the apache error log (see my signature).