@Wayne-Workman - FOG 1.2.0 running on Ubuntu 12.04 LTS. The drive did fail during normal operation - i.e. after running for several days, it got suddenly disconnected, I’m almost sure it’s a hardware issue (either the drive itself or the SATA controller). After reboot it mounts normally and the images resync on the other node.

Well, there is a lot of guesswork involved as we are not sitting in front of the machine. But you could help us to help you by capturing a packet dump on your FOG server. Fire up this on your server tcpdump -i eth0 -w pxeboot.pcap udp and let it sit there while you are getting up that machine causing the issue. As soon as you see the error hit CTRL+C to stop tcpdump and upload the PCAP-file to the forum here.

@EAHarvey said:

@Wayne-Workman So you’re talking about when i initially upload the image correct?

Not really. I’m talking about you creating your own task type. To be honest I’ve not used this plugin yet, but I’m fairly sure it’s possible to do what I’ve described.

@hlcstudy I’d say - dont delete any of the images manually.

The web interface can delete files via FTP for you. You have to click on the actual image you want to delete first. then on the left in it’s menu, at the bottom, you’ll see “Delete”. You also have to check a checkbox to confirm you want to delete the image AND it’s data.

Errors (or warnings as the case is here) does not mean anything in particular. I’m adding checking to return if the value is true, and throwing an error if the value is false. If the error is thrown, it also returns false. My guess is this is specific to when you’re inserting, or updating, and entry and this is why you’re seeing this error. I’ve added, as I stated earlier, a better check mechanism so it will simply return if the value is true and not attempt iterating over a boolean value.

4806 Should have this ready and working for you.

@tecnomuzik Your suspicion with the 5 minute upload along with @Uncle-Frank 's is correct. It normally takes two to five times longer to upload an image - depending on compression settings.

Best would be to hook the client to a hub and capture traffic from there.

Second best if you can capture TFTP-DHCP and FOG-server at the same time. I should be able to “synchronize” those two dump files by looking at the broadcast packets.

And as a quick try you might just capture on the TFTP-DHCP server. Hopefully I am able to make the missing packets up myself.

Useful tcpdump options:

-i eth0 capture interface, change to suit your needs -w outfile.pcap write packets to PCAP file (you won’t see the packets while capturing!) As last parameter you can add capture filters but this is quite tricky when it comes to PXE boot and DHCP (several different protocols and ports). You can simply use udp as a filter or not port 22 to keep your SSH session out of the way. Sometimes host x.x.x.x is also great but not in this case here.

@isaiah658 It’s not an issue, honestly. We have these forums to help everyone with all problems related to FOG. In the future, someone might read this thread and be helped by it - so people here helping you doesn’t just help you but potentially helps many people across a large span of time.

@Tom-Elliott Tom I can confirm that I had to do a FULL wipe as well for it to work. I think it may be database related. I upgraded to the latest, took a copy of the DB then did a FULL wipe. Tested it and everything worked. Restored the database backup, and it started the issue again. Not a huge deal since I have my snapshots and went to a known working version again though.

@EAHarvey I’ve found it mostly depends on the Firmware HDD Operation mode.

Sounds a bit like an issue others had too. See here: https://forums.fogproject.org/topic/3072/imaging-stuck-on-upload-after-finished and here https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP#Images_won.27t_finish_uploading.2C_won.27t_go_past_.22Clearing_ntfs_flag.22

Cool, so I’ve solved this thread then. Thanks for reporting back.

Hello,
Problem solved.
First of all, big thanks to Tom Elliott for support.
The problem was the MAC, was registered as a “Pending MAC”.
Regards.

Yeah I marked at solved a 3 years old topic !

with latest svn the problem is solved

@AsGF2MX said:

I actually didn’t have to use the has usb nic parameter for any unit. I used the USB-0301 as mentioned earlier and it didn’t complain on any of the units I had imaged with FOG.

Wow… who would have thought? Wonder why it worked?

I’ll be adding your isc-dhcp configuration to our WiKi sometime today, to the BIOS & UEFI coexistence article here: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence

Great to see that you got it solved yourself. Quite different to how I would have done it but that’s the good thing about FOG and IT in gerneral: There is always more than one way of doing it. Have fun with FOG!

@Tom-Elliott Very good!! That was the solution! Thanks.

The client requires .NET 4+. Most windows systems will automatically have it if they perform windows updates. Granted if someone skips the .NET 4 framework Window’s update then the computer won’t have it.

Thanks for all your help guys. Finally got it working. It was the draytek in the end. They seem to be a bit odd with DHCP option 66. Setting the option from the web interface wasn’t working so in the end had to do the following from telnet:

srv dhcp option -e 1 -1 [lan number] -s [Fog Server IP]

not sure what the -s flag is but it worked after that.

Couldn’t find anything about this on the net so hopefully this will help someone else in the future!

Thanks again!