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

This typically happens when the computer previously had it’s HDD in GPT layout because the computer was previously in UEFI mode, and is changed to BIOS mode, and had Windows re-installed, thus changing the HDD layout to MBR.

The Windows installer does a crappy job at setting up MBR, it leaves pieces of the old GPT layout behind. There is a utility to fix this, it’s called fixparts and it’s available to you already via a debug capture or debug deploy.

In the web interface, choose to capture like you did before. On the confirmation page for capturing, check the box for “Debug”, then confirm this.

When the computer network boots, it’ll go to a prompt. It’ll display two chunks of information, you have to press the ENTER key to pass through this information. Eventually you will find yourself at a shell (a shell prompt). This is a Linux environment, btw.

Generally, the drive you need to work with is /dev/sda but this isn’t always the case. You can get a listing of the local drives by typing the lsblk command. Say for you the local hdd is named /dev/sda, the command to type to fix the disk layout would then be fixparts /dev/sda

After getting this utility going, if it says the disk is dirty, follow onscreen instructions to fix it, and then to write changes to disk. When done, type the fog command to start the image capture process, because this is debug it’ll ask you to press ENTER at every step, it’s important to do this all the way to the end.

@educapole said in FOG 1.3RC13 TFTP error:

@Tom-Elliott Indeed, i’ve found a second DHCP server on my network. An user has plug a damn wifi acces point…

Bingo!! and those dang wifi access points with built in dhcp will point to them selves as the next hop server so the clients will try to download the boot image from them.

Good find.

This has been added to the wiki here: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_TFTP#Please_enter_tftp_server:

@jmer129 That’s exactly what this file is used for. It maintains which partitions should be “fixed” or set as it was when the image was originally captured.

@dureal99d Your welcome. I’m glad in the end it was just a simple reboot that finally resolved the issue.

We had a hour or so chat session to work through this issue pulling apart the dhcp/pxe booting process frame by frame.

@TomBagley Thanks for reporting back! Marking this solved then.

My initial reaction is that you don’t have the sata driver for the P 650 G1 in your reference image.

Second reaction is what type of disk is in the 650 G1 (is it a NVMe type disk)? If so you will need to include the OS kbs that add support to NVMe disks. This is outside of what hardware drivers are needed for that model.