Oh I know. I followed that wiki to the T for both Ubuntu 14.04 and Debian 7.7, and I was still having issues. So it really didn’t help me directly, although it was a good reference point for confirming the dhcp options as well as the commands to disable the firewall in Debian.

The underlying problem was that there were individual DHCP options set for a couple of our VLANs, but not all of the Vlans. So they were over riding the global options that I was working with.

I don’t expect the wiki to delve into Windows based DHCP management, but might be worth a line around the DHCP section, that explains…
“It is possible to have these options configured on your DHCP server per subnet/vlan. So make sure there is no conflicting information in the specific subnet you are working in.”

Until it was mentioned in the post regarding DHCP settings per subnet, I didn’t have a clue that was even possible. Now that I know, I have actually configured the old .32 server on a specific maint vlan and the new machine on the production vlan, so our technicians can still access the older images in an emergency.

Thanks again for the feedback though. I appreciate it.

FYI, so far the newer version of fog (1.2) on Debian 7.7 has corrected many of my incompatible hardware issues right out of the box.

Wonderful community work everyone. Special thanks to you Tom.

Haha, Tom you are a savior. Upon further review of the DHCP options I have found my problem. I have a global setting on the DHCP, but apparently either a) MS auto copies that rule into each subnet, or b) I set up the rule for each subnet individuall when I stood the first server up and don’t remember doing it.

Either way, I went to the particular vlan I was working with and found its own set of 66/67 rules there. I made them match the new servers information and presto, it worked.

Now I can continue working with some of my testing. I may come back for assistance on getting these newer NIC cards working on this system IF I have trouble with it. I am hoping that the newer server version will straighten all of that out though…

Again thanks for kicking that ‘ah-ha’ moment out of me everyone.

Will keep you posted.

Ok, so I have run those three commands, the two rm/ln commands passed whilie the ufw was unrecognized. I do remember that I exec’d the following commands already on this Debian install from my previous research on wiki…

[CODE]iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT[/CODE]

I am looking into the DHCP server options, per vlan now, as you had mentioned earlier.

Thanks,

I just realized you want me to run the ufw command, is that a Debian command?

I had tried that back when I was fooling with Ubuntu 14.04, but have not tried it since moving to Debian 7.7. Hopefully that was my misunderstanding and that will fix my issues.

Again, thanks for the time so far, I really appreciate it.

[quote=“Tom Elliott, post: 38419, member: 7271”]Are you setting the options per subnet or at the server level? I’ve heard of similar problems if you’ve only setup for the “global” setting rather than specifying at the subnet level.[/quote]

I am specifying it at a global level.

[quote=“Tom Elliott, post: 38419, member: 7271”]Another, quick, test, would be to maybe ensure tftp is correct by removing the /var/lib/tftp folder and creating a symlink to it:
[code]sudo ufw disable #disables firewall.
sudo rm -rf /var/lib/tftp
sudo ln -s /tftpboot /var/lib/tftp[/code][/quote]

I will try this and get back to you, but one question… If it was a firewall issue, would my tftp attempt from a command prompt on a windows machines still be succesful? It is always succesful, well, since I fixed the open timout issue that was ocurring anyway.

Thanks for the ideas, will post as soon as I have more information.

[quote=“Tom Elliott, post: 38412, member: 7271”]Did you set your dhcp server’s option 66/next-server (ip) and option 67/filename (undionly.kpxe)?[/quote]

Yes I do have these options set properly. The odd thing is, if I change the next ip to my old server and change the file name from the undionly.kpxe to the pxelinux.0 file everything works fine with the old server.

[quote=“ArchFan, post: 38414, member: 19266”]Does restarting the TFTP service have any effect?
[CODE]
sudo restart tftpd-hpa
[/CODE][/quote]

At first I was gettig the TFTP Error: Open Time Out error. Stopping and restarting the service corrected this issue and it now opens the connection, but the file not found error comes up.

Thanks and keep them coming. I appreciate the help.

I have been unsuccesful in standing this new version of fog up on its own, despite currently having a .32 server running in production.

My current issue is during the PXE boot process the systems fail with a message of ‘File Not Found’

Here are my details.

Fresh install of Debian 7.7
Fresh install of FOG 1.2

Installation went fine. My config does not use the fog server as the DHCP server. I have modified my DHCP rules on the Windows server to reflect the change in IP and the change in file name (undionly.kpxe)

Every time I use PXE to boot i get the typical TFTP error, file not found.
When I go to a windows based machine and use the TFTP command prompt to ‘get’ the undionly.kpxe, it passes successfully.
I have confirmed that the tftpd-hpa file has the correct tftp directory entered (/tftpboot)
I have tried with 0.0.0.0:69 in the config file as well and the ip (10.18.16:69) to no avail.
I have also scoured the forums, and wiki for solutions. So much so, in fact, that I decided to go with Debian after reading several people having issues with Ubuntu 14.04. So I have effectively installed this system from the ground up, three times…

I cant’ understand why a tftp command in windows will transfer the file succesfully, yet no system will boot to the PXE menu.

I am a nix(Debian) noob, but I should add that we currenlty have a Fog .32 server running on Ubuntu. I set this server up and we have used it for a little over a year now with great success.

I initially started this upgrade as a stand alone install because I fear the loss of valuable data and images from the existing system with an in place upgrade.

I started looking at upgrading as a result of our newer systems network cards not being compatible with the fog system. I was hoping that the updated version might be a bit more reliable when it comes to client hardware compatibility.

Please help me out, if possible. If you experts believe that a different approach is a better solution, then so be it. Likewise, if you think that an upgrade of this nature will not likely solve any of my hardware compatiblility issues then I will give up on the project and continue to suppliment our new systems with PCI cards to accomodate the ghosting process.

Can’t wait to hear back from someone.

Thanks,

Moved to new thread due to age of this post…

I too have the exact same issue. I just remove the card, ghost it, and then install the card after the system is up and running. A pain, but a working solution for now.

We have 2 (110 units) generations of systems in our organization that have this video card, so a solution would be awesome!