HP 250 G4 and HP 450 G3 Network connectivity issues.
-
@george1421 exactly what im doing right now. Will post the update in just a bit
-
@ragarces Also please try this - on an affected computer, just disconnect the patch cable, wait like 10 seconds, plug it back in.
See what happens (try to renew the dhcp leaseipconfig /release && ipconfig /renew
). -
reloading right now, because as soon as i remove the driver from windows, queue up the laptop to reimage, restart the imaging process is good. So right now, Im going to reload to make sure the drivers are good.
-
Dang. Reloading didnt do anything. Still hit an miss on obtaining an IP. Really stumped with these 2 models. Dont have any issues with the other close to 40 images we have except these 2.
-
@ragarces Lets just recap here since its been a few days.
You have 2 system specific images one for a HP 450 G3 and one for a HP 250 G4. Both are notebooks. Once imaged neither one of these computer models pick up an IP address once the system has been imaged with FOG.
So to the questions:
- Does the reference image work fine before its captured with FOG image capture?
- On the deployed image, if you manually remove the network adapter and then reboot does the target computer re-identify the network adapter and recreate the network interface?
- What happens if you download the latest network drivers from HP site and manually/force upgrade the network drivers on these target computers?
- Is this just an ethernet issue or are you having problems with both ethernet and WiFi connections?
- Where these systems sysprep’d or did you just power them off and imaged them?
If I understand the above I have two thoughts
- At this time I can’t see how this is a FOG issue, or something that FOG would do/care about. So I unless there is something else I’ve missed we can rule out FOG as being a culprit here.
- I have see issues with driver shadowing in the past. Where there is a built in windows driver that closely resembles a hardware device and that gets loaded over/before an more appropriate vendor driver. (while this is a bit off point, I saw this with a sound driver on a Dell 780. If the windows native sound driver was used the sound driver worked perfectly with external speakers, but the internal speaker did not work. Once we loaded the proper dell audio driver both the internal and external speakers worked perfectly. This is the kind of driver shadowing I’m talking about).
-
I can see how this appears to be a Windows issue, but I firmly believe it is a kernel problem. I believe it has nothing to do with imaging, but simply loading the Linux kernel on these machines is corrupting the nic’s firmware. My users are experiencing the same thing, here are 2 unrelated posts that show something similar. Can someone bring Tom into this since he seems to know a lot about the kernels, to get his thoughts? I too would like to find a resolution for this.
http://forum.clonedeploy.org/193-pcie-nic-issues-after-imaging
http://forum.clonedeploy.org/55-old-hardware-pxe-e05 -
@jdd49 While I don’t believe its a linux issue because if you turn off the computer and back on any “bad stuff” that linux might do to these machines should be gone. The FOS engine (kernel) doesn’t (AFAIK) update any firmware so there is nothing to leave behind.
If you re-image one of these machines with the windows DVD does it work correctly? I would still like the 5 questions I asked answered too. They will help the developers understand your current landscape too.
@Developers Do you have any ideas here?
-
@george1421 the kernels do load fw files for some NICs. The only issue I’ve seen though is it simply can’t boot to HDD after loaf up. what fixed this issue for my issue systems was using the ipxe.pxe file instead of undionly.kpxe.
-
Mind you I suspect it’s how the nic is loaded initially on the ipxe side vs an issue with kernels or Windows though successfully booting to Windows would fix the nic issue initially.
-
@Tom-Elliott said in HP 250 G4 and HP 450 G3 Network connectivity issues.:
Mind you I suspect it’s how the nic is loaded initially on the ipxe side vs an issue with kernels or Windows though successfully booting to Windows would fix the nic issue initially.
Right that is what I’m thinking, but correct me if I’m wrong. Any changes that he linux kernel might make to the system would not survive a power reset. I have seen where when the linux kernel exits and the next OS takes over, that the next OS doesn’t properly init the nic (or what ever hardware device) assuming it was default when booted.
In the OPs case, when the system is image and restarted and (I assume OOBE is run) that the NIC isn’t picking up an IP address. And to my point if you power off the computer and reboot it there should be no remnants of linux left behind.
-
@george1421 it depends how the nic is designed to handle the fw but typically yes a full/cold power start should correct for that iteration.