@robtitian16 Tutorial most appropriately names: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Post the pcap to a google drive/dropbox/etc and then share the link, either in a forum or IM me the link and that will tell us what is going on. It really helps to have the fog server, dhcp server, and pxe booting client on the same vlan to see the entire conversation. If that’s not possible, you can use wireshark on a notebook on the same vlan as the pxe target computer to capture at least the dhcp process. That is where the process is failing.

Just looking at the picture very closely I see you are using multipart all disks (mpa). I see in the picture you have both a NVMe disk and a standard hard drive mcblk0 and sda. The problem with the mcblk0 it has two boot blocks that aren’t really usable. Are you trying to clone both the nvme and sda disks? Or since you are using mpa are the source and target disk sizes the same? Since you are using non-resizable?

This article may help you to update: https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

Also there is a error log file in a directory next to the installfog.sh script. Look in that sub directory to see what is behind the error “Backing up database…”

If you can explain things better in your language please do so, we can translate with google too. I will only answer in us english because that is what I think in.

@deimos First the shaming… Its not helpful to mask the IP address of the device unless you have a public IP address range. There is no way for me to hack you if you are on 192.168.0.0 range externally.

Is your FOG server and this target server on the same subnet?

Usually I like to collect more information, but I think we should jump right into a packet capture of the pxe booting process to tell us what is going on: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

If your fog server is on the same subnet as the target computer, use the fog server to collect this information so we can see the entire pxe booting process. If its on a different subnet then use wireshark with the same capture filter to capture the dhcp process. The wireshark computer needs to be on the same subnet as the target pxe booting computer.

You can either review with wireshark on ubuntu, or upload it to a google drive and share the link either here or send me an IM with the link and I will review it.

@hanz If you wouldn’t mind, please expand on what you had to set in the GPO to correct this. Your solution will probably help the next FOG Admin who’s pulling his hair out trying to understand what happened…

@entr0py said in Error Restoring Images - Clients having identity crisis:

MSI

Can I ask you to post to this thread: https://forums.fogproject.org/topic/10987/what-can-we-do-when-we-don-t-trust-uuid With the inventory data from one of those MSI boards? We only need one entry unless you have different computer models than mainstream Dell,HP,Lenovo. We are looking for a good example of different mobo manufacturers and how they populate smbios (what FOG queries to identify the target machines).

well that really didn’t help readability at all.

But it looks like its a database issue. You might want to review this thread and see if it addresses the issue. https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

Especially if FOG was working one day and its broken the next day without any intentional changes.

On each fog server (normal or storage node) there is a linux account called fog. This is not the default web gui admin called fog but a linux account by the same name. Your storage node configuration needs to match the user ID and password correctly for the linux account. If these were complete fog installs the linux user fog’s password will be in a hidden file in /opt/fog directory called .fogsettings. Review this file on each fog server and be sure the storage node configuration is consistent with these files.

@sudburr Since this is a new fog server install, did you remember to disable selinux as well as stop the firewall?

The permission denied is a new one for me. I have to look that one up. It might be the file permissions in /tftpboot, but I need to research that a bit.

First I would say, make sure you upgrade to the latest RC10.

I don’t think that is your problem, but the devs will request you do that anyway so they can help.

What I find strange is why all of your target computers have the same mac address? How is this possible?

1. What kind of servers are we talking about here?
2. What OS are you running?
3. Are these physical servers or virtual?
4. If these are windows servers, was the master image ever connected to AD before it was captured?

There is something going on here beyond what you posted.

Since FOG seems to be using SANBOOT for exiting is your HP Server in BIOS (legacy) mode or UEFI. The answer is different based on the mode the server firmware is in.

For this server, go into the host definition. Lets assume this sever is in bios mode, change the BIOS exit type to GRUB First Hard Drive. Hint: You may need to experiment with the ext types to find the right one that works with your hardware. The rEFInd exit type is for UEFI hardware.

The other thing I can say (at least for my company) we don’t have servers pxe boot through FOG. When we go to image a physical machine we press the F10 or F12 to bring up the boot manager during the system POST. Then from the boot manager we select PXE boot into FOG. This way we are sure there is no way to accidentally reimage a server. We have a rule that a technician must be in front of the server before it is allowed to be reimaged. If you use this method the hard drive is always defined first in the boot order.

@kevin-talbot What would be interesting to see is this…

Use a disk bench marking tool like CrystalDiskMark and compare the write performance between the two disks. The tool used doesn’t matter you just need to use the same tool on both systems to get a relative index between the two drives. The most important number for FOG imaging is sequential writes.

@sjensen Yes a snapshot would let you roll the changes back to a known good condition. Just don’t forget to integrate your snapshot into the VM once you have proven that the update is successful.

@sjensen The first link that Wayne posted speaks directly to your need. Just don’t execute any git checkout xxxxx commands unless you want to upgrade to a development release. I can say that 1.5.0 RC10 (git checkout dev-branch) is pretty stable and does fix a few issues that exist in 1.4.4. stable.

@greg-plamondon Well there is a couple of things I see in this setup that made me squint a bit. (not in any particular order)

1. You have 8 vCPUs allocated to this VM. (initial reaction: a bit overkill). But more to the point, your VM Host server is using an Intel E5440 processor. That CPU has 4 cores without hyperthreading. Lets assume that that VM Host server has 2 physical CPU chips. So that gives you 8 physical cores. That means to run the FOG VM all 8 cores have to be in a ready state to run the FOG server. So there may be a hypervisor scheduling issue on the VM host. If it was me, I would drop the vCPU count to 4, maybe 2 to start and watch the utilization.
   Ref: http://www.gabesvirtualworld.com/how-too-many-vcpus-can-negatively-affect-your-performance/
2. Disconnect the Centos 7 iso image from the cdrom
3. You have a check-in time of 60 seconds, so that means you will have 300 some clients hitting your master fog server every minute. You may want to change that to 300 or 900 seconds. Understand the impact of this in that when you schedule snapin deployment tasks the clients won’t see the task until they check in. But in most cases a 5 or 15 minute check in for snapin deployments are not going to hurt you.
4. It looks like mysql is taking a beating from the clients. You can see this in the mysql and apache high processes tasks.
5. Depending on how long mysql has been in service in this fog install, we may need to run some mysql clean up and reindexing commands (I don’t have them handy at the moment)
6. We might be able to help with performance by switching over to a dedicated php engine (I have a document on that I can dig up in the forums).
7. Physical memory doesn’t seem to an issue with the VM so you should be good there.

I would focus on dropping the vCPU count and extending the check in periods first. Then assess the next steps.

So why is fog slow on the initial login? Its probably related to FOG creating and caching your session from the sql database that is being beat up.

@tmerrick Then take that same the same filter (without the -w wol.pcap flag) and use wireshark on a laptop. Connect it to that subnet. WOL packets are broadcast packets so if its being generated on that subnet you should trap it.

I can’t speak about the root user, but if you happened to create a system user called fog for normal system maintenance, the fog installer creates or captures that user account for its internal service account. Understand this is the linux user fog and not the webgui default administrator of the same name fog

Please understand this is not the function of FOG. FOG is a high performance disk imaging tool. Not a live boot system.

With that said, its possible with certain configurations to turn the FOG server into a netboot server. https://forums.fogproject.org/topic/11194/poc-using-fog-as-a-netboot-server

You might want to review this tutorial too: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

@palermo Deploy that disk image file (d1p1.img) to either real hardware or a virtual machine. Understand FOG is a disk imaging tool not a live boot or VDI environment.