@itachi_19 There is something going on here because both conditions can’t happen tcpdump sees nothing but dhcpd responds to a client request.
Are you running tcpdump as root or sudoing to it? If you don’t have elevated rights I can understand why tcpdump would not see (because tcpdump can’t connect to the raw socket).
Yes, both are VMs on a Virtualbox, and their network is set to NAT.
Well that would keep the witness computer from seeing this communication. With NAT enabled that still doesn’t explain where the tftp://10.0.2.4/Windows@2010.pxe “Windows 10.pxe” file name is coming from. As they say, the culprit has to be in the house (virtualbox).
@Oleg I lost track of this but stumbled upon it just now. Thinking some more about it I find that we should not try to fix this within the FOG installer. We have done so many times and it just makes it a nightmare to keep up to date with the different OS requirements and specifics…
So you might follow the steps Tom outlined some time ago - maybe you already did. If you need more detailed information on that, then let us know.
@julio You need to look into who installing those programs on Ubuntu/Debian is possible at all. For example, Notepad++ is a native Windows program and seems like you need to use snap (on Ubuntu) or even manually install wine to be able to run Notepad++ on Linux: https://itsfoss.com/notepad-plus-plus-linux/
Putty is available as official package on Ubuntu and Debian as far as I found.
An so on. This is well beyond what we can do for you! You need to figure out how the installations work or ask in different forums specific to that software you want to install. Start by searching the web.
As soon as you figured out how to install each software you can use bash scripts (mentioned below) to do the job for you.
@julio This is a new error for me. If the destination is failing to deploy I think there should be a different error. But I give you steps to debug this.
Schedule another deploy task to this computer, but before you press the “schedule task” button, select the “debug” check box then submit the task.
PXE boot the target computer. The computer will start into the imaging steps, but this time you will see many pages of text that you will clear by pressing the enter key. At the end of the text you will then be at the “FOS Linux” command prompt.
At the “FOS Linux” command prompt key in lsblk. This will show you if FOS Linux can see the local hard drive.
The next step you will start the imaging process. In debug mode the imaging process will pause at certain steps. This is done so you can read errors during imaging. I am guessing since your deployment is failing, there is an error message that is getting overlooked. I might think there will be an error message on the partclone screens (blue screen with text). To start the imaging process at the FOS Linux command screen key in fog and press enter. You will need to press the enter key at each pause to go to the next steps.
@emreonder Sorry for my late reply. Lost track of this over the holidays.
I am still at a loss on why your partition looks like this. What is the extended partition actually used for?
Beside that I can’t really guess what might be special about this setup/layout that prevents it from chainloading to disk after iPXE is loaded on the Gigabyte motherboard. We know it works on other hardware and therefore I’d think the bootloader on disk is being properly imaged through FOG.
/dev/sdb = /images
/dev/sdc = /opt/fog/snapins
I 100% agree with this route AND to add create the partitions on the disk as standard partitions and not LVM volumes. If they are standard partitions you can expand them easier than a LVM volume (debatable) if you are running the fog server on a V and need to grow your storage.