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

@Obsidian reported that replication worked fine after he setup his remote servers as Storage Nodes, as recommended.

Also, this topic has gone off topic, and has been forked to here:
https://forums.fogproject.org/topic/8747/when-restoring-image-disk-not-found

@Wayne-Workman He already did, it’s how I know it was already pushed and is working.

@george1421 ,
Hi,
with Intel I5/I7 processor the system start correct,
j1900 e3826 reboot (it’s not a fog problem but ACHI driver installed ).

Hye,

I 've update to rc14 and now it’s working.

Thanks

In addition to below, on your FOG server please key in showmount -e 127.0.0.1 that will show what is exported (shared via nfs) on your FOG server.

@smazzola said in I am trying to image a lab of Dell Precision 1700's.:

@sudburr

I created the image in UEFI mode. I had to turn on the Legacy Roms in order to get the device to pxe. However, I never took the device out of UEFI mode. I used the same settings on the machine I brought the image down to.

But, the image was captured in UEFI mode. This hasn’t changed. The destination computers must be configured in exactly the way the source computer was configured - before you changed things around - in order for the image to boot as expected on the destination computers.

Please read through my previous post.

@TThax You don’t need to actually download the client. The latest kernel, init, and client gets downloaded automatically when you run the fog installer. You just need to update to the latest FOG release candidate, run that installer, and you should be good to go.