@cnkpadobi removed. If its there it will be read. If you are concerned about the content then move them to /root (root’s home) or some other location, but not in the /ete/dnsmasq.d path.
Posts made by george1421
-
RE: Issues booting UEFI devices a
-
RE: Issues booting UEFI devices a
@cnkpadobi lets remove all but the correct one (like the one I posted). We can only have one configuration file in there with the options I provided. AND if that is the case /etc/dnsmasq.conf should remain unchanged from the original install.
I would suggest that we keep the standard file of /etc/dnsmasq.d/ltsp.conf and then remove the rest.
-
RE: Issues booting UEFI devices a
@cnkpadobi said in Issues booting UEFI devices a:
@george1421 so if I run the
sudo netstat -an|grep 4011
it should give me something correct versus taking me back to the prompt?If it takes you back to the command prompt, then that tells us the dnsmasq is NOT running on your fog server.
-
RE: Issues booting UEFI devices a
@cnkpadobi said in Issues booting UEFI devices a:
ltps.conf ltsp.conf ltsp.conf~ network-manager README
I don’t quite understand the above line. Taking it out of context it appears there are more than one configuration file.
- ltps.conf
- ltsp.conf
- ltsp.conf~
In that directory.
-
RE: Failed to get an ip from DHCP ! Tried on interfaces eth0 eth0 .
@kleanthis said in Failed to get an ip from DHCP ! Tried on interfaces eth0 eth0 .:
New Switches were installed that only have FastEthernet
?? FastEthernet == 100Mhz ??
-
RE: Failed to get an ip from DHCP ! Tried on interfaces eth0 eth0 .
@kleanthis said in Failed to get an ip from DHCP ! Tried on interfaces eth0 eth0 .:
@Tom-Elliott Well why cant my lan 1 and 2 get an ip but lan 3 can . This is my actual question . Otherwise when an os is installed all lan ports work fine .
(sorry working at my real job right now).
What I find stange is that the link light is not coming on, on this lan1 lan2 interface. The link light is a hardware/software function. If there is a functioning network jack, the light should come on.
From the FOS side, its seeing the network adapters AND talking to them since its getting a mac address from the network adapters. So FOS is happy with the network adapters.
I might understand why they are not getting an IP address depending on how FOS manages the network adapters. We may need to issue the dhcp command again on these interfaces (once we can understand why they link light is not coming on).
-
RE: Failed to get an ip from DHCP ! Tried on interfaces eth0 eth0 .
@kleanthis OK now we know the order that FOS is seeing the interfaces.
eth0: 00:0b:ab:70:9a:21 (192.168.1.111) eth1: 00:0b:ab:70:aa:69 eth2: 00:0b:ab:70:aa:6a
If this was a typical “server” I would say that eth0 is considered an add on network adapter (which is typically discovered first) and then the built in network adapters (eth1 and eth2). Where eth1 and eth2 mac address are consistent with a dual port network adapter. What’s happening is understandable.
For the sake of discussion, if you plug in the other two nics and run the
ip addr show
again, do the other interfaces get an IP address too? You may loose access via putty when you do that, but you can still key things in on the FOS console.The bigger question now is why isn’t FOS testing each network interface for an up link. Right now it sounds like its giving up after testing eth0 (LAN3) and not continuing to loop.
-
RE: Failed to get an ip from DHCP ! Tried on interfaces eth0 eth0 .
@george1421 When you get to the FOS command line, if you give root a password, you can connect to the FOS engine via putty to help with any copy paste operations you need.
at the FOS command line key in
ip addr show
to get the device’s IP address
then key inpasswd
and give root a password. It doesn’t matter what password you give it, as long as its not blank. From there you can connect to the FOS engine using putty and login asroot
and what ever password you give it. Then you can run the debugging commands from there. -
RE: Failed to get an ip from DHCP ! Tried on interfaces eth0 eth0 .
@kleanthis what we “need” is to get to the linux command prompt on the target computer THEN key in
ip addr show
, orip link show
. From the output then we can see the reference between ethX and mac address. That will help us identify what FOS “thinks” eth0 is.Don’t worry about breaking what you were just able to do, we are NOT going to start the deploy/capture as long as debug was enabled.
-
RE: Failed to get an ip from DHCP ! Tried on interfaces eth0 eth0 .
@kleanthis Its simple. Just schedule another capture/deploy to the same target. Since you have LAN3 working use that interface. But before you submit the task select the check box that says debug.
This tells FOS to not start the task automatically but drop the user to a linux command line. This is what the developers use to debug the FOS engine.
-
RE: Failed to get an ip from DHCP ! Tried on interfaces eth0 eth0 .
@kleanthis it would be interesting (again) to setup a debug deploy/capture to get access to the FOS engine command line. I’m suspecting that FOS is setting the eth0, eth1, eth2 order based on hardware discovery order, which seems to be inconsistent with what the iPXE kernel is doing.
-
RE: Failed to get an ip from DHCP ! Tried on interfaces eth0 eth0 .
/dev using udev : error creating epoll fd
That is just a warning message and is not related to your current issue.
OK I think the next step is to manually register this device and setup a debug capture/deploy (what ever you were doing). A debug deploy/capture will instruct the FOS engine to drop you to a command line on the target computer. From there we need to do some debugging commands like
ip addr show
to see if any ip address is being picked up by any interface.OK so can we say that RC10 was also defective in regards to this system too?
-
RE: Failed to get an ip from DHCP ! Tried on interfaces eth0 eth0 .
@kleanthis what version of FOG were you on before you updated to RC16.
What version of FOG was the last one you remembered worked correctly with this device? I know the FOS kernel (bzImage) was updated with RC14 (I think). If we can narrow down when it worked vs now we may be able to point to the kernel update that is at fault.
-
RE: Failed to get an ip from DHCP ! Tried on interfaces eth0 eth0 .
@kleanthis Outside of this embedded device, does imaging work correctly on traditional office computers?
Looking into the data sheet this device has 3 network adapters, each has a different model number. LAN 1 Intel 82567V GbE, LAN 2 Intel 82583V GbE, LAN 3 Intel 82541PI GbE
I wonder if FOS is picking an interface that doesn’t have a network adapter as its primary.
-
RE: Failed to get an ip from DHCP ! Tried on interfaces eth0 eth0 .
@kleanthis It sounds like the FOS engine (bzImage + init.xz) is making it to the target computer, but when FOS initializes it can’t find the network/pickup and pickup an ip address. Did this issue just start with RC16?
This sounds like a spanning tree issue, but its strange it would just start. Could you test something for us? Please place an unmanaged network switch between the pxe booting computer and your building network switch. See if that solves the dhcp issue.
Also for the sake of completeness, what is the the target hardware that is having an issue right now.
-
RE: Issues booting UEFI devices a
@cnkpadobi are there any other config files in the /etc/dnsmasq.d directory?
dnsmasq will read all configuration files in /etc/dnsmasq.d directory. If there is more than one that has conflicting settings it will throw an error.
Now there is another check to see if dnsmasq is running
netstat -an|grep 4011
It should return something that looks like this if its running. Port 4011 is managed by dnsmasq.sudo netstat -an|grep 4011 udp 0 0 0.0.0.0:4011 0.0.0.0:*
-
RE: Issues booting UEFI devices a
@cnkpadobi ok what is the illegal keyword on line 2 of the config?
-
RE: Issues booting UEFI devices a
@cnkpadobi
For what ever reason your pcap didn’t make it to the FOG server. Could you post it again, please.Looking at the pcap file. I’m not seeing a normal dhcp conversation going on.
I see the clients sending a discover request and the watchguard dhcp server sending an offer, but then the client instead of sending a request packet goes back to sending another discover packet again. And what is troubling is that dnsmasq never responded to the pxe clients discover request. Are you sure the dnsmasq service is running on your fog server?
ps aux|grep dnsmasq
should return something -
RE: File to file network backup (Not a tutorial yet)
Software like FOG and Clonezilla do backups based on the block level. They image the entire drive, block by block. For what you want to back up, you really need a file level backup so that you can restore the files post imaging instead of the entire disk (as you would with FOG).
Now you could pxe boot a live image of linux (i.e. puppy linux) and copy off the user files to a nfs share, then image the system, then pxe boot again using a live linux and copy them back.
I can tell you that when we migrate users at our office, we use USMT to copy their profile and files to a network share. Clone the system and then at the end use USMT to copy the files back to the new system. This is then all done in the windows realm.