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

@dhamodaran said:

its taking hours of the time to upload and download.

What does your network environment look like? What kind of and how many switches are between client and server? Which image type is configured? Maybe RAW?

Could you please help us with some more information. OS? FOG version (see cloud on the web interface)? Model (e.g. HP 8200 …)? USB devices connected?

As Tom said the message about USB is probably not causing the issue…

@giejo63 said:

When i try the URL with hostname.php it keeps trying but nothing happens

You mean in a web browser?? Wow… this is… not as it should be I guess!

What do you see in the apache error logs while you try to access this URL from a browser. Depending on your distribution those files might be in /var/log/apache2/ or some similar path on the FOG server.

@Tom-Elliott CrucibleWDS has resizeable LVM working.

Thanks for the reply.

I setup a router to be able to test the ports for the storage node. So far these are the only ports i needed to open:

FTP – tcp 20,21
HTTP - tcp 80
SSH – tcp 22

I haven’t tried to register a new host and install it yet, but now the Dashboard displays the Storage Node, and image replication works.

@Tom-Elliott
thanks for explanation.
Regards