@idiart33 Ok is there a tftp log in /var/logs directory? There has to be a clue somewhere why the tftp server isn’t starting.

You could also try to manually start it to see if there is any usable hints.

cd /etc/init.d
./tftpd-hpa start

I don’t know what status 71 is, but I’m hoping it will tell us what it doesn’t like.

@bartont126 Remember with great power comes great responsibility. Use the following commands with care.

Use this commands to see what directories are from failed uploads (yes they do take up space)

ls -la /images/dev

Get the list of directories that appear to be mac addresses. Then run this command replacing <mac_address> completely with the directory names. Remember executing this command is unrecoverable.

rm -rf /images/dev/<mac_address>

The -rf makes the command dangerous. -r == recursive meaning do it on that directory/file and all objects below. -f == force or just do it and don’t ask questions.

You can check the disk usage with this command before and after to see how much free space you made du -sh /images/dev

You have a 7390 is it in bios or uefi mode? If is in uefi mode is the disk controller in raid-on mode or ahci mode?

@vpt So did you boot the image you are trying to capture and run check disk “chkdsk /f”? There is something wrong with the structure of that disk you are trying to capture.

@vpt That first error is saying that windows was probably shutdown incorrectly for image cloning. This happens when someone just uses the shutdown start menu button. With fast boot enabled in windows, shutdown is really an enhanced sleep state. Its really not “shutdown” what we would think it is.

So what can you do?
Shutdown the windows computer properly for cloning by:

1. If you use sysprep add the /shutdown switch to properly power off the computer for image cloning.
2. If you don’t use sysprep then key in shutdown.exe -s -t 0 from a command window.

To understand what is happening here you can google “windows dirty bit”.

@idiart33 OK the issue here is that the tftp service can’t start, it can’t bind to the ipv4 socket. This typically means that there is already a service running bound to that socket. So far there is no other problems other than tftp, so you don’t need to look at fog settings at the moment. Having to hand edit the default.ipxe file means that you do have some fixup to do with fog because the IP address changed after you installed FOG.

STOP... I just looked at your previous posts "In the /tftpboot/pxelinux.cfg/default file I had a bad IP." why is syslinux installed on this computer? FOG uses iPXE for its boot loader. This tells me you don't have a standard FOG install. Are you installing FOG side by side with another opensource project?

Lets first try to understand why tftp is not starting.

Please run these command:

systemctl status tftpd-hpa

Make sure the service is still in the state of not being able to bind to the socket.

Then run:

netstat -an|grep :69

You should not get any response.

If you get a response like below you already have a tftp service running on your computer. I’m going t guess you WILL get a response like below, but lets see.

netstat -an|grep :69
udp        0      0 0.0.0.0:69              0.0.0.0:*

Another test would be this command:

ps aux|grep tftp

With the status of can not bind to the socket, I would expect this to return some value too. What this test does is to check to see if a service with tftp in the name is running in memory.

@bartont126 First being on 4.11.0 is the root of the issue with l219-V network adapter. That support was added into the 4.12.0 linux kernel. So close but not quite.

There is no guide to manually update the kernels because its not recommended you do by hand. With that said download the kernels from here: https://fogproject.org/kernels/

Download Kernel.TomElliott.4.19.6.64 and save it as bzImage
Download Kernel.TomElliott.4.19.6.32 and save it as bzImage32

Move both of those files to your FOG server in the following directory
/var/www/html/fog/service/ipxe
-or- this if the above errors out
/var/www/fog/service/ipxe/

Note: you will probably want to rename the existing files before you move these new kernels in place just in case you need to backup for some reason.

@arnaudrigole said in Dell Optiplex 7060 - getHardDisk error:

I used that trick to switch between “raid on” and “AHCI” during more than one year right now, and it worked well but…

Now we got NVMe SSDs in our new DELL computers, which need to be configured in “Raid ON” as “Sata Operation” to boot on Windows. Do you think that “GetHardDisk” error will be fixed in next versions ?

I think you have two different issues here. The first issue is the raid-on vs ahci mode. This is an age old issue between Intel, Linux, and uefi. With these three amigos working together linux can’t currently see any disks behind this configuration. If you change any of the three (really two) linux will see the disk. From what I understand the issue is related to intel not releasing the uefi raid drivers to the linux community.

The second issue may be new Dell hardware with these NVMe disks.

1. What version of FOG are you using?
2. What version of FOS Linux kernel do you have installed?
3. What is the model number of the computer with this issue?

@agray When you setup vitrualbox did you add in the virtualbox extension pack? The reason why I ask is that your network settings appear correct. I’d have to look at my home linux laptop to be 100% absolute. I know pxe booting does work with virtualbox into fog because I do testing at home often.

This appears to be more of an issue with virtualbox than FOG since your physical machine works correctly.

@agray I would say that looks like a normal pcap except I don’t see it transferring the file. If you look at the pcap we see a Discover, Offer, Request, and ACK. Then the client request the file size of undionly.kpxe and then requests the file… from there it stops. Then after 30 seconds or so it sends out a discover again and the fog server responds with an offer but then it cycles between discover and offer.

So my question is this: Does this happen with the VM only, where a physical computer boots normally?

I might understand what is happening but not the why just yet. I did notice that the mac address of the device in your picture doesn’t match the mac address of the pxe booting device in the pcap [08:00:27:8a:86:44].

@agray I guess the question needs to be asked are you running the dhcp server on the fog server for a reason in addition to the dhcp server on your router?

Which dhcp server do you want to run? I understand the goal is to pxe boot your clients but there is a number of ways to go about it, depending on what your main goal is.