PXE boot problem
-
@Jaymes Driver: I have already done this. Thanks
@variable205: I’d like to avoid dealing with these guys, but I might have to do it if there is no other solution.Thanks to both of you for your answers.
-
[quote=“George_Lebay, post: 28436, member: 24393”]@Jaymes Driver: I have already done this. Thanks
@variable205: I’d like to avoid dealing with these guys, but I might have to do it if there is no other solution.Thanks to both of you for your answers.[/quote]
Pay attention to this part:
Serving ProxyDHCP to multiple subnets
If you are serving ProxyDHCP to multiple subnets some changes must be made to your switches/routers and your server config.
Modify your /etc/dnsmasq.d/ltsp.conf file by adding the subnet mask option to line:
dhcp-range=192.168.1.10,proxy
to make it
dhcp-range=192.168.1.10,proxy,255.255.0.0
which will serve all 192.168.x.x subnets. If you are using 10.x.x.x addressing, use subnet mask “255.0.0.0” (8-bit) and if you are using 172.16.x.x, use subnet mask “255.240.0.0” (12 bit). Basically set the subnet mask so that all subnets on which ProxyDHCP should answer are covered. If you don’t do this, the ProxyDHCP server will not respond to DHCP requests for hosts outside of it’s own subnet.
Add an IP Helper/DHCP Relay record to your router or switch so the DHCP broadcasts are sent to your normal DHCP server AND the Fog server.Add the correct setting to your ltsp.conf file and restart the dnsmasq service.
-
I’ve read that part on the “Using FOG with an unmodifiable DHCP server/ Using FOG with no DHCP server” page, but all my computers are in the same subnet at the moment. At first the server was on a different one, I have changed the IP address to see if it would change anything, but obviously it didn’t.
BTW the computer that is able to PXE boot and the client on which it’s not working are in the same subnet.
-
The only difference is that unmanaged switch that links the server to the client that actually pxe boot to FOG.
-
[quote=“George_Lebay, post: 28448, member: 24393”]The only difference is that unmanaged switch that links the server to the client that actually pxe boot to FOG.[/quote]
So if your ip address scheme was 10.1.1.x ALL clients on the network get the same 10.1.1.x ip address, is this correct? they may increase to 10.1.2.x or 10.1.6.x, but everything must increase sequentially. If that is the case you need to look into the switch gear between your DHCP and your clients that can’t boot.
This is not a problem of FOG, your FOG server is working, and if your dnsmasq is working to boot your machines on one side of the switch but not the other, it is a setting in the network gear.
If you move one of the clients that “can’t boot” on one side of the switch to the side that does allow booting, does the client boot properly?
-
[I]So if your ip address scheme was 10.1.1.x ALL clients on the network get the same 10.1.1.x ip address, is this correct?[/I]
That is correct.[I]If you move one of the clients that “can’t boot” on one side of the switch to the side that does allow booting, does the client boot properly? [/I]
Yes. I have tried and it works. -
Then the problem lies in the network gear, you need to check the settings or talk to someone that manages the DHCP server to better understand why it is you can not pass boot information over. My GUESS is that there is a setting on one of the other switches that is preventing communication.
-
[quote=“Jaymes Driver, post: 28483, member: 3582”]Then the problem lies in the network gear, you need to check the settings or talk to someone that manages the DHCP server to better understand why it is you can not pass boot information over. My GUESS is that there is a setting on one of the other switches that is preventing communication.[/quote]
To add on, it’s probably blocking UDP traffic altogether so I’ll go out on a limb and think the “Managed” side of the switch has Multicast Broadcasting Disabled. I’ll go even further and I’m going to guess that Wake On Lan functionality probably doesn’t work either.
-
I am getting DCHP/BootP: Reply not for us, op[2] xid[642c17ed] and other xid codes. This now happens only after I create a task to download an image to a client.
-
[quote=“Oscar Hilliker, post: 28485, member: 24172”]I am getting DCHP/BootP: Reply not for us, op[2] xid[642c17ed] and other xid codes. This now happens only after I create a task to download an image to a client.[/quote]
Can you create your own thread?
This sounds more like your environment has VoIP’s?
-
[quote=“Tom Elliott, post: 28484, member: 7271”]To add on, it’s probably blocking UDP traffic altogether so I’ll go out on a limb and think the “Managed” side of the switch has Multicast Broadcasting Disabled. I’ll go even further and I’m going to guess that Wake On Lan functionality probably doesn’t work either.[/quote]
If it works with the Ghost Console, is it supposed to work with Fog ? Are the settings on the switch the same ?
-
[quote=“George_Lebay, post: 28496, member: 24393”]If it works with the Ghost Console, is it supposed to work with Fog ? Are the settings on the switch the same ?[/quote]
Incorrect, they are two systems and because one client works in one, do not assume it will work in another. while FOG is versatile and we can add drivers to accommodate systems, there are still some issues we have not yet over come. If a machine supports the PXE boot method, it can be used with FOG.
The settings may or may not be the same, but it couldn’t hurt to check to see if the proper settings are turned on, that is if you have access to the administration settings.
