HP EliteDesk 705 G2 MINI
-
This is on ANY system with the same nic?
It seems the system you’re testing might have a bad nic, but this is just a guess.
-
I might also suggest updating the BIOS in the case there’s a problem with the nic:
http://ftp.hp.com/pub/softpaq/sp78001-78500/sp78296.exe
These are just the nic drivers, if I’m reading into this correctly.
http://ftp.hp.com/pub/softpaq/sp78501-79000/sp78852.exeANd full software driver information:
https://support.hp.com/us-en/drivers/selfservice/hp-elitedesk-705-g2-desktop-mini-pc/7633235 -
@Tom-Elliott
I have tried 3 of the 50Pcs we have and 2 have registered and not imaged, 1 has failed to register.I have updated one to the latest BIOS using the built-in updater
It all appears to work fine under Windows and our image will work with it, and install the drivers once the PC has it on the disk.
I found this bug report on kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=12877It looks like the bug fixed in 2009 has kicked in again.
I shall register there and see what I can do to get it fixed. -
@Andrew-ASPH Just to recap where we are at.
The current linux kernel that FOS uses doesn’t support these nics.
A Commercial (so to speak) Linux distribution also can not init these nics.
The workstation has been fully patch with firmware updates.
-
@george1421
That is correct, It is looking like a Kernel bug, so FOG will have to await a fix in a future kernel. I’m not sure who in teh Kernel devs would be best to talk to about getting the tg3 driver fixed however. -
I had the same problem with HP EliteDesk 705 G2 Mini and the G3 Mini too.
I figured out a way to clone the machines, but I don’t know exactly what the problem is, not even the solution.
When I used a new network cable connected to a 1000Mbps port, the cloning process goes perfectly, however when I use a 100Mbps port on the same switch, the error always occurs.
I had to use my single gigabit port to clone all machines, 1-by-1.
I reduced the server’s port speed from 1000Mbps to 100Mbps, forcing it to work at 100Mbps, but the gigabit port is the only one that keeps running. -
I did another test, I had already changed the switch port where my server is connected to 100Mbps and had left the port where my machine is in Auto [1000], every things perfect. When I changed the machine port to a fixed value of 100Mbps, the problem began to occur in the port that previously worked.
I’m not sure, but I think I’ve already tried to create an image on another machine model on a 100Mbps port and the problem did not occur. Is this a problem on HP’s PC, which only accepts network boot at 1000Mbps?
-
@joaoguedes
I have tested as well, and these PCs only image when connected to a gigabit port, No all I have to do is persuade the network manager to let me have gigabit ports for imaging rarther than the standard 100Mb he restricts everyone to. -
@Andrew-ASPH I’m glad you guys found a way to work around this. That network adapter must not have a very good network speed negotiation protocol.
I can also imaging that imaging at 100Mb/s (12.5MB/s) would not be much fun. On a 1GbE network we typically see about 6GB per minute (~100 MB/s) transfer rates, with a 15GB image taking about 4 minutes.
-
@andrew-asph
Hello, I’m having the very same issue. We’re trying to work around this since last semester, and the best we could get was to create a set of scripts in order to use fog files for MANUAL cloning, without network (ouch!). Basically we managed to:-
Grab an image using a single ethernet cable (crossover), with gigabit board on both ends and NO SWITCH in between. One of the machines was NOT the HP (hence, it most probably has another kind of NIC).
-
Copy fog files to an external, usb hard disk. Adjust scripts to fix paths.
-
Boot a live ubuntu from a memory stick (already prepared with the necessary tools inside).
-
Run the scripts, in order to setup the gpt partitioning and the disk deploy
My machines are “HP EliteDesk 705 G3 MINI” (G3 instead of G2), but most probably the motherboard is the same. Or at least close enough to have the same issue. The process has to be repeated for every single machine (yeah, it’s a pain). Here it takes about 50 minutes each, when everything works fine (over USB 3).
Maybe you would like to take a look at the issue I created. It has a lot of information, including kernel logs and such. Just updated it today. Here it is. Maybe when a fix (or workaround) is found in the future, you can use it too.
Regards,
Paulo -
-
@andrew-asph
Hello, today I just managed to make it work, based on directions provided by the fog team. I will double check it tomorrow, but the details (and the patch) are all described on the other thread (please see my last message in this thread).By the way, if any of you could repeat what I did in order to check that my findings also work for you, it would provide valuable evidence that the issue was nailed. Can you please try the fix and report the results? Any result will help, since a failure can show that there’s something else that I missed.
Looking forward for your testing.
Regards,
Paulo -
@andrew-asph
Hello, this thread has a patch that solved the bug.
https://www.mail-archive.com/netdev@vger.kernel.org/msg189347.htmlThe patch is here:
https://www.mail-archive.com/netdev@vger.kernel.org/msg189923/0001-tg3-Add-clock-override-support-for-5762.patchMore details in here:
https://forums.fogproject.org/topic/10731/crash-due-to-timeout-in-tg3-kernel-module-tg3_stop_block-timed-out-ofs-4c00-enable_bit-2?loggedin=true
