@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.

@fritoss007 said in LDAP authentication with userPrincipalName fill with email address: Should I report it somewhere else In this tread is good enough. Both Tom and Sebastian are in this thread so its the right place at the right time.

Just one thing, i can boot only on uefi. It’s a long story…

@george1421 This is on an i3 NUC and its F10 to get into the boot manager. Then in the bios you need to make sure the uefi network booting is an option

@Oleg said: I don’t know if it has to do something with the timeout issue but in /etc/default/grub I added We don’t use GRUB for PXE booting hosts usually! Seems like you have customized your setup a fair bit. I may ask you to tell us more about the customization to we are able to properly help you! I changed manually the kernels in /var/www/html/fog/service/ipxe/ to the 4.15.2 Kernel. With the older kernel the issue with the timeout is gone. That’s interesting. So it seems like a Linux kernel network driver issue from what we know so far. Let’s start by trying to find out what driver is used. Please boot Windows on that machine, open device management and get us the device ID from there. Usually in the form 12c4:5f78.

@george1421 so far it’s only 2 out of the 12 I’ve done. If I hit boot from hard disk it will go to the drive, but otherwise nothing happens. Tried it multiple times.

Yes, the Dell Latitude 3189 are laptops that do not have internet ports and we had to use USB adapters. At that time, the version of FOG didn’t like same MACs for multiple machines. So the way I got around that was deleting the hosts since it was tied to a MAC from a USB and I was more concerned with just getting them imaged. I guess I deleted them prematurely. Unless I just overlooked something completely and did something wrong. As for the deploy task ones, I’m not sure why they were stuck in there. They may have been ones that seemed to be giving me imaging problems and I turned off the machine before canceling it in the task menu.

@george1421 said in better web performance?: … "I could just copy the 443 virtualhost as 444"but instead of creating a virtual host just setup https on your fog server. There is really 2 sides to this equation. First you have all of the fog inner workings of pxe booting and fog clients. Leave them on port 80. Second use your enterprise ssl certificates on the https port. (actually I’m going to be doing something similar in about a week to our fog server because more browsers are complaining about http sites.) I’ve started outlining a basic (hack) configuration here to add ssl support to the FOG sever without much pain or messing with PXE or FOG Clients. https://forums.fogproject.org/topic/14464/adding-https-support-to-fog-server-with-centos-7 So far its working.