ProBook 450 G9 slow to image
-
Been using Fog for just over a year so still a Newbie. We are a school district with a mix of Dell & HP machines. All our systems image on average of 12-14GB/min. We just received a handful of ProBook G9’s which barely get 2GB/min. I know this isn’t the end-of-the-world problems but why so slow? Our G6, G7 and G8 HP’s image fast. My very limited knowledge thinks it’s the Fog Kernel, which hasn’t been updated in a bit, doesn’t have a fully optimized driver? Is there a way around this?
-
@Scootframer Don’t think the G9 has been discussed in the forums much yet. But there is a history for the other models:
https://forums.fogproject.org/topic/15132/hp-probook-640-g8-imaging-extremely-slowly
https://forums.fogproject.org/topic/15623/partclone-freezes-or-crawls-after-kernel-updateMy very limited knowledge thinks it’s the Fog Kernel, which hasn’t been updated in a bit, doesn’t have a fully optimized driver? Is there a way around this?
Can’t promise you anything but lets start by gathering some more information to see what can be done. What version of FOG do you use and which FOS kernel version is installed (output of command
file /var/www/{,html}/fog/service/ipxe/bzImage*run in the FOG server console)? -
@Scootframer said in ProBook 450 G9 slow to image:
All our systems image on average of 12-14GB/min
While this comment doesn’t help your current situation, I would say this is a typical speed (~13GB/s) for a virtualized FOG server connected to a well managed 10Gbs core network, using contemporary target hardware (end user computer) connected via a 1Gb/s uplink. This are speeds I would expect to see. So your FOG install is working at a nice speed.
As for these Probooks, we have seen this issue with new models every generation or so. While I don’t have experience with these HP computers, I’ll guess that they have realtek network adapters. Realtek likes to change up their network designs every few years, but use the same name for the network adapter (i.e. rtl 6168), It takes the linux kernel developers time to catch up to the realtek chip sets. If you are not running the 5.15.x or 6.x kernel branch this slowness might be the problem. Understand I don’t know if updating the kernel will solve the problem, but you will have a better chance with the latest FOG released kernel for imaging.
-
@Scootframer Hello,
I have a similar problem on my 630/640/650 G8.
But … if i check, in BIOS, this option, the speed deploy is “normal” : Advanced > System Options > cocher « Configure Storage Controller for VMD ».After deploy, i need to uncheck before the first boot. If i don’t do that, i have a BSOD.
PS : i don’t use any RAID configuration. -
R repier89 referenced this topic on
-
Hello
I’m experiencing the same problem with HP ProTower G9, but with the added bonus of randomness
I’m using Fog 1.5.9 and kernel 5.10*.
The first PC, I deploy an image very quickly but it freezes at the end, perhaps a network cut. Impossible to restart the deployment, it deploys at 5Mb / min or something like that.
2nd identical PC, I deploy the image at high speed. I modify it and capture it just as quickly.
3rd identical PC, impossible to bring the image down quickly. I decide to update the Linux kernel to version 6.1.63. There’s some improvement, it’s stable between 400 and 600 MB/min. It’s not as fast as my previous deployments.
I don’t know what to do to improve this knowing that I have to deploy 13 other new PCs by Wednesday.
Thank you all for this tool that I love!
-
I have very good news.
While analyzing the chipset of the network card, I realized that it was an Intel (and not a realtek) I219-LM and that it was an old chipset.
So I downloaded the bzImage 5.15.98 kernel and made it available in the appropriate folder on the FOG server, calling it bzImage_5.15.98.
Then, in the host description, I put bzImage_5.15.98 in front of the machine kernel.
And oh magic, everything went back to the way it was before 13 GB/mn
-
@Bristow-0 That IS very strange that going to the older kernel solved the issue. I’m glad you have it worked out, but maybe the devs need to look into the 6.x kernel a bit more. I can understand that there was a big jump in the kernel code with the 6.x release.
