Some hosts are unable to get an address through DHCP
-
@mageta52 said:
Will the logs show how many addresses are leased? Is there some place i can check?
DHCP leases should be in
/var/lib/dhcp/dhcpd.leases. At least it is here on debian. My syslog is saying this when I restart the DHCP service:... ... dhcpd: Wrote 22 leases to leases file. ...Or use dnsmasq in proxy mode!? Although I have to admit that I don’t find dnsmasq’s proxy mode to be that good - it has limitations when it comes to serving BIOS and UEFI - it still might be a way to go for you.
But as Wayne already said, adding PXE booting options to the existing DHCP server is definitely the best way to go and shouldn’t conflict with anything in your network. Talk to your network guys.
-
Our engineer does not want the server on the core network. Apparently the switches on the core network are not set up to handle multicast and it creates issues.
I looked at the logs and it said that it wrote 44 leases to to the lease file, there should still be more than enough addresses. Not sure why it’s attempting to hand out 192.168.235.17 with each attempt.
-
@mageta52 If that’s his only reason, you could just not use multicast. I used to, but unicast is so fast I just use that now.
I looked over the dhcpd.conf file and interface info you posted a few days ago trying to find a problem, I didn’t see anything. I spent a good amount of time picking it over. The only thing that might even be an issue is the dns update style, since there is no DNS server on your isolated network. But I doubt this is causing the issues.
Maybe we should try to re-approach the problem with more simple troubleshooting? I’d like to.
Look inside of /var/log for system errors. I’d look through OS errors, any journalctl errors. I/O errors, and ensure again that firewall is indeed off and SELinux is disabled.
Wherever you put the fog installation files, just use those to reinstall fog. You’ll need an Internet connection for fog trunk to run the installer but only temporarily.
Try a different switch. An un-managed dumb switch.
Is the cabling or server nearby high voltage equipment, electric motors, HVAC equipment, manufacturing equipment, a microwave, or very close florescent lighting? These things will cause RF noise and can interfere with network communications and motherboards, ram, power supplies, and so on.
Do a MemTest on your FOG Server, you can use a bootable CD or flash drive to do this.
Do you have a power supply tester you can use on the fog server’s power supply?
Unplug peripherals if any, all the fog server needs is a network cable and a power cable.
-
@Sebastian-Roth I’m afraid I have not gotten to imaging multiple clients at once yet, is it possible to image a bunch of them at a time using unicast? If so, what is the purpose of even having the multicast feature?
-
@mageta52 Unicast vs. multicast is like trying to explain the same topic to several people one at a time vs. giving a speech where the audience is more or less just listening. Sure you can unicast to a bunch of computers and I know people who use unicast for mass-deployment. So yes it works. But being kind of a network guy for me this feels like a huge wast of resources as your switch(es) need to shuffle around a lot of extra packets just for the sake of it.
That said give unicast a try. Put a couple of your machines together in a group and start a unicast deploy for that group…
-
@mageta52 A tip, I limit my fog server’s maximum connections to 2.
So when I fire up a imaging task of 30 computers, only two run, the rest wait in line until a slot is open and then begin.
-
Why do you limit it to only 2 at a time? Is it faster?
-
@mageta52 For me, it is. It might be different for you.
So, if you start 10 at once, each successive one that starts runs a bit slower.
This slowness does not speed up if bandwidth is freed up by other hosts completing.
So, the slowest one is always the last to finish and it takes forever.
By limiting it to two here at my work, the two run at full speed, the only limiting factor is the target host’s speed of writing to disk.
My recommendation is to see how many you can run simultaneously before you detect any slowdown with the later joining hosts. Minus one from that number and that’s the sweet spot.
-
@Wayne-Workman So, we run open dhcp on our main network. What I’m not sure about, is how to point that towards the fog server if a client is PXE booting and looking to connect.
-
@mageta52 Windows DHCP:
DHCP Scope (global or individual) -> Option 66 = ip address/hostname of where to get PXE information (FOG Server IP Address).
DHCP Scope (global or individual) -> Option 67 = filename to try to get from the PXE server (undionly.kkpxe).
-
@mageta52 also, after doing what @Tom-Elliott said, you can setup UEFI support as well by following this: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence
-
@Wayne-Workman Thanks guys, I’ll try to experiment with these options, again, it will probably have to wait until next week. The schedule is insane right now.
-
@Wayne-Workman said:
So, if you start 10 at once, each successive one that starts runs a bit slower.
This slowness does not speed up if bandwidth is freed up by other hosts completing.Unicast is just the wrong “tool” to send out lots of identical data to many clients… Sorry, couldn’t hold it back.
Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
@Sebastian-Roth I agree. But I also don’t have access to my building’s switches to fix multicast.
