@foggystarz You might want to look through this thread for ideas for pxe booting recovery media with FOG: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images/3?_=1590418175520

@Derek-Newbold As a very first step I may ask you to post a picture of the error that you see on screen when an image does not properly deploy “due to image size being set to 0”. While I can’t be absolutely sure (there have been many changes and fixes since FOG 1.5.4) I am not aware of the image size playing any role when deploying an image to a host! It’s true that in FOG 1.5.4 the image size on client field is being updated and set to 0 if it fails deploying and that is something strange we fixed lately. It will only ever do this on captures now. Nevertheless I don’t think the image size should influence the deployment process in any way. Please provide error messages.

OMG it’s working I spent like 5 hours searching for a solution and now it’s done by your answer. you are the best bro thanks :)))))))))))))))))))

@jdmiller323 @jmvela2x Is this still causing you trouble or were you able to set it up?

@george1421 Thanks!, Got it… I will try your solutions it’s make sense. :)

@ITHand Have you read through this topic start to end? May I ask you to do the database queries mentioned below and see if you can find out if one of the MAC addresses is already in the DB and which one it is. Take a very close look at all the network interfaces you have in your network manager on Windows - also tunnel interfaces and such.

@Real1987 What does this have to do with FOG imaging solution? Is this after deploying an image to the 3400? What version of FOG do you have? What OS is in the image? What type is it set to (resizable or non-resizable)? Is BIOS set to legacy mode or UEFI? Many more questions arise, but we might start with those.

@wafflest1ck said in Install Issue: the issue is that our network is pretty tight What exactly do you mean by this?

@lelinh Hello and welcome to the FOG project forums. Have you got FOG installed yet? Which version? Anything we can help you with?

@fritoss007 I can give you a hackers approach at doing what you want with the registration process. FOG calls fog.man.reg to invoke the registration process. You can find the source of this program here: https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.man.reg If you understand bash shell programming you can make modifications to this program to alter it registration. I will give you a hint to use notepad++ to edit this file because windows notepad add extra windows junk into the file that will cause error messages during execution. So now you have this file how can you inject it into the FOS Linux booting process? You can do the recommended method to unpack and repack the inits as Sebastian outlined. Take a bit of the hacker approach and use a FOG pre-startup script (i.e. post init script) to copy the fog.man.reg from the FOG server to the FOS Linux disk as FOS Linux boots. If you look at this tutorial: https://forums.fogproject.org/topic/14278/creating-custom-hostname-default-for-fog-man-reg in the section called fog.patch.customhostname you can see how to “patch” FOS Linux as it boots.

@DennisRentAll Let’s take one step back here. Is this a fresh clean install of FOG showing this issue or has this worked before and the problem turned up just now? What Linux OS is this running on? Firewall disabled? SELinux disabled?

@UWPVIOLATOR said in Error trying to restore GPT partition tables. Exit returned code 4: I uploaded it again and I didn’t do anything different and it worked. It’s very strange you don’t seem to get consistent results with this. I have seen converted MBR/GPT partition layouts that caused such an issue but those didn’t fix themselves! Could it be something with FOG running into issues capturing? Do you see any errors when capturing? May I ask you to rename the /images/000-1909UEFI/ folder to /images/000-1909UEFI_bak1/ and re-capture again. See if it deploys properly or fails. Try go get two image directories, one that is causing the deploy error and one that doesn’t. Then grab all the files from both image directories except the large d1pX.img files, ZIP them up, upload to a fileshare and post a link here! I will take a look. I saw in update notes that there has been some error checking added. Is that possibly the issue? Can you be more precise on what you saw and where? There have been hundreds of changes since FOG 1.5.6 and I am not sure what you mean.

@scosta It’s good you ask in the forums before taking this step. Better to consider this thoroughly than heading into it blindly. A few things come to my mind: FOG 1.5.9 is on the doorstep and I suggest you wait for that! Between 1.5.4 and 1.5.5 (and later!) where was a major change in the way FOG replicates images and snapins. See the important notice in the official release statement. So I would say updating main server and all storage nodes in mandatory in this case - at least for all the nodes that get the images replicated. Have you used ClusterSSH before? In my last job I updated our servers by the lot - like 12 or so in one go. If you have a screen huge enough you could do even more I suppose. We don’t support offline updating as of now. But if you are keen you could hack the installer script to skip the steps that need a connection to the internet.

@sbenson But the other location was fast at one time. Or the root of the issue is the location IS the difference that causes speed issues??

@fritoss007 This may help too, as I believe @Sebastian-Roth has made this script native to the github fogproject code, and can be run at any time: https://github.com/FOGProject/fogproject/blob/master/utils/FOGiPXE/buildipxe.sh

@zyzhang Yes you can delete an image through the web UI and it will delete it on disk as well. But you have to make sure you use the delete button in the image settings view - not the multi delete from the list view!

@zyzhang Yes you can delete an image through the web UI and it will delete it on disk as well. But you have to make sure you use the delete button in the image settings view - not the multi delete from the list view!

As I just stumbled upon this topic again I might update as well. This is fixed upstream and we already use the version fixed by buildroot in version 2020.02.2.

Hey rhromyko! Thank you for that information! I was having the same problem.