@John-L-Clark Hi, have you solved your problem ?

@HSD3Tech Hi, have you solved your problem ?

For further clarification to future readers of this thread, the specific commands to allow the necessary ports for Multicast can be found in the CentOS 7 wiki article, linked below.
https://wiki.fogproject.org/wiki/index.php?title=CentOS_7

@george1421 Thank you for the tip. I copied values from .../ipxe/boot.php?mac=<mac_address_you_just_deployed_to> and now it works.

@Quazz Yes, quite a few things are altered.

Fairly sure it is fixed now. Just awaiting confirmation. I had it fixed, but accidentally reverted a portion of the patch. Re-re-released and all should be well.

as for the “replacing the computer name” issue check the testpc primary mac address for “Ignore client” and this should prevent changing the hostname to testpc.

@pencils Get a new copy of Ubuntu, because something is wrong with yours.

@pencils You can leave the first one empty, I believe as it refers to the name most commonly, whereas the second has to be the IP.

I corrected it, thank you.

In Red Hat land, apache’s service is called httpd and I have a habit of typing that from muscle memory. Thanks for pointing out the mistake!

And wow, you hopped on that fast? I only added System Rescue CD to the wiki in the last two days lol.

@Wayne-Workman Hi Wayne,

That did the job! Thank you very much for this you may mark resolved!!

Tom

@88fingerslukee Thanks for the remote session. I’d have never found it. This makes sense though. The other threads that had the issue only stated the uncommented it and things worked, I didn’t know this was happening on any re-install.

https://forums.fogproject.org/topic/8758/fog-installation-error-cannot-restart-mysql/9#

I’ve found and fixed the cause of the issue. It was my scans looking to correct other issues. I didn’t realize some distros were adding that particular if statement. Sorry 😞

https://forums.fogproject.org/topic/8758/fog-installation-error-cannot-restart-mysql/9#

I’ve found and fixed the cause of the commenting randomly appearing.

@inst It turned out to be a hardware issue. The solution was to use different hardware. If this doesn’t fix it for you, I too would suggest opening a different thread.

@noelpd I concur with Sebastian. You need to try a dumb unmanaged mini-switch between the computer and the building. Most I.T. places have a few laying around. If you don’t have one, they are pretty cheap to get - you should go out and get one.

You should also try brand-new patch cables too.

@mageta52 Ok, no problem.

The proper tcpdump filter that will show us what is going on without showing things that you shouldn’t post to an open forum is this.
tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011
This will record only dhcp, tftp, and dhcpProxy traffic. Start this running on the FOG server then pxe boot the target computer (on the same subnet) until the target errors out then hit ctrl-C on tcpdump and review with wireshark or post it hear for review.

alt text

Another tidbit of information I don’t know where to put in the wiki.

I think I should create a new article just on common FOG kernel arguments.

Just wanted to reply here, I just had the “TFTP open timeout” error at home, it ended up being a bad patch cable. Simply replacing the cable with a new one solved the issue.

The original HDD as reported by Gnome Partition Editor 0.26.1-5:

Partition | Name | Label | File System | Flags /dev/sda1 | EFI system partition | | fat32 | boot, hidden, esp /dev/sda2 | Microsoft reserved partition | | unknown | msftres /dev/sda3 | Basic data partition | Windows |ntfs | msftdata /dev/sda4 | Basic data partition | WinRE_DRV |ntfs | hidden, diag

Editing d1.fixed_size_partitions of the captured image to be:

:1:2:4

… then deploying the image to a smaller HDD results in this:

* Attempting to expand/fill partitions ... Done * Seems like you are trying to restore to an empty disk. Be aware this will most probably cause trouble. Attempting to deploy image Using Partclone An error has been detected! No image file(s) found that would match the partition(s) to be restored (performRestore> Args Passed: /dev/sda /images/test all Computer will reboot in 1 minute

Deploying the same image to a larger (500 GB) HDD results in:

Partition | Name | Label | File System | Flags /dev/sda1 | EFI system partition | | fat32 | boot, esp /dev/sda2 | Microsoft reserved partition | | unknown | msftres /dev/sda3 | Basic data partition | Windows | ntfs | msftdata (still shrunk at 25.4 GB) unallocated (211.82 GB) /dev/sda4 | Basic data partition | WinRE_DRV | ntfs | hidden, diag (correctly sized to 1000 MB) unallocated (227.29 GB)

GParted initially launches with this error:

Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 2014 blocks) or continue with the current setting?

Selecting FIX or IGNORE doesn’t change the partitions.

So it more or less mirrored the original 256 GB HDD layout onto the 500 GB HDD leaving the extra space after sda4 empty, instead of dumping sda4 onto the end of the space, then expanding sda3 into the donut hole.