Posts made by george1421

Just be aware that IPMI is not the same a WOL. And not all servers support WOL and / or IPMI. For the R610, you either need to have the BMC programed to respond to IPMI commands or have a drac card installed to respond to IPMI. I have not personally tested to see if WOL actually works with a R6x0 system. I seem to remember something about it only working on eth0 (or the first built in network adapter).

To remove FOG from the equation, get a third party WOL program and see if you can wake up the R610 externally.

Solarwinds free WOL
http://www.solarwinds.com/free-tools/wake-on-lan

Or free version of Emco Wake on lan
https://wake-on-lan.net/

The key here is to first establish that you can’t wol these servers. I’m aware that some devices will respond to different magic packets, so that also comes into play.

It “might” be interesting to see if FOG could send ipmi messages at some point in the future, hint, hint…

@Tom-Elliott Are we trapping the call to the wol command someplace in a log to see if its being called differently?

@cajos001 one might wonder if there’s a powershell way to add local printers?

Maybe something like this ps script from our friends at Admin Arsenal: https://www.adminarsenal.com/blog/how-to-add-printers-with-powershell/

FWIW: Power shell scripts can be deployed as a FOG snapins. I might suspect that someone with a bit of skills could deploy the driver to the remote host and then run a powershell script to add it to the windows environment.

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

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

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

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

1. ltps.conf
2. ltsp.conf
3. ltsp.conf~

In that directory.

@bacprotr49 Excellent. Is it OK to close this ticket?

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

@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).

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

@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 in passwd 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 as root and what ever password you give it. Then you can run the debugging commands from there.

@kleanthis what we “need” is to get to the linux command prompt on the target computer THEN key in ip addr show, or ip 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.

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

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

@kleanthis

/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?

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

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

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

@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:*