Solved. After eliminating one item after another, and initially only looking at the NIC, I went ahead and removed the DMS card. Wouldn’t you know it, no longer the rEFInd error and they went on to image. Thanks for everyone’s suggestions. This goes to show that some errors are not really related to what they appear to. 40 + machines saved from surplus.

@gazzer82 You should be able to use the efibootmgr tool if the machine is properly booting in UEFI mode. Please describe in more detail how you boot from USB. One time you say pxelinux (which is really old and not used by FOG since years) and then you say rEFInd…

If you boot up to a FOS debug shell run efibootmgr, take a picture of the output and post here.

@Shad0wguy said in HP Elitebook g6 slow to image:

where the first image will deploy without issue, but then subsequent deployments hang.

Can you clarify what “subsequent deployments” mean? Is that to the same device you are deploying again, or are you deploying to a different device and it hangs?

Is the hang with image push from fog or WinSetup/OOBE provisioning of the device?

If it is a different device, is there anything that is being shared between the two devices? What happens if you reboot the fog server when the subsequent devices hang?

What version of FOG are you using?

thank you 🙂

@sysengine1125 What is serving DHCP in your network? A Windows Server? Which version?

@weidongyan said in How to make fog server using my new storage pool:

The storage pool that I created has been mounted.

To which path is it mounted?? As well post the output of the commands George requested!

@TBCS Are all the Yogas in a specific part of your network (one switch/room/subnet)? It’s kind of unlikely this is caused by the Yogas being UEFI systems. What could be the case is that the network driver for the NIC used (probably an external adapter, right?) is kind of buggy and not allowing for a proper NFS connection. But as we check network connection on bootup it’s also very unlikely.

I guess George is on the right track here. Your network seems to not handle the default 0.7 second timeout well and therefore you see random failures. Try manual mounting as George suggested a couple of times in a row to see how often it fails.

mkdir /testfs mount -o nolock,proto=tcp,rsize=32768,intr,noatime 10.10.1.93:/images /testfs umount /testfs mount -o nolock,proto=tcp,rsize=32768,intr,noatime 10.10.1.93:/images /testfs umount /testfs ...

Then add the timeout option as well and see if it’s doing any better.

mount -o timeo=10,nolock,proto=tcp,rsize=32768,intr,noatime 10.10.1.93:/images /testfs umount /testfs mount -o timeo=20,nolock,proto=tcp,rsize=32768,intr,noatime 10.10.1.93:/images /testfs umount /testfs ...

Hi, I am having the exact same issue, with the Optiplex 3020’s. Were you able to find a solution?

There is currently no way to work around the secure boot issue.

To boot with secure boot on the boot OS needs to have a signed certificate. This certification process requires both iPXE (from another FOSS project) and FOS (from the FOG Project) to be digitally signed. Getting these items signed and certified is time consuming and expensive (from a FOSS standpoint).

@Sebastian-Roth Thanks you!!! I swapped out the ipxe.kpxe file and it worked.

@george1421 Got it. I made the changes and in the process of deploying my first image now. Appreciate the help.

Server

FOG Version: 1.5.6 OS: Debian 9.9 Kernel: 4.19.48 TomElliott 64 and 4.19.48 TomElliott 32

Client

Model: Lenovo X1 Carbon Gen6 Dock: Lenovo Dock USB-C DK1633 OS: Windows 10 Pro 64 Secure boot: disabled

Description
Hello,

I’ve the same problem on Lenovo X1 Gen 6.
As @george1421 suggested, I turned to FOS. Unfortunately I don’t understand the documentation to build an image.

Thanks for your help.

Solution
This works well with the adapter provided by Lenovo.

@george1421 Just wanted to let you know that I updated to the latest kernel as suggested and it worked! Not sure if anyone else has the same issue, but now we can image about 630 PCs! You guys rock!

@Zark110 Just as a quick test an you connect a dumb unmanaged switch between the client and your main switch? Then try again.

@Sebastian-Roth Intel Core i5-7260U @ 2.2GHz * -shrugs- *

If I may interject with a very hypothetical statement. If you end up using the fog client portion of this solution on more than say a few hundred hosts, you may think about making the server a bit beefier. Here is my setup

For my 1500 hosts that check in with the client:

4 vcpu’s
8GB RAM
250GB storage (we use model specific images)

May be overkill but it works pretty well for me

@Sebastian-Roth So just out of a combination of desperation and curiosity, I tried a different computer with the same exact specs. Changing to AHCI worked. The original computer works fine except for this one FOG issue. I booted into Windows, ran chkdsk, installed a program, rebooted and everything worked like there wasn’t a problem. I reinstalled Windows with the Dell USB recovery disk and FOG was able to pull an AHCI mode image. Out of 15 computers, two had this issue. I think this is a fluke with Dell. Thanks for both your guys’ help.

@Sebastian-Roth Found a firmware update for the model and took a peek at it’s change log. Didn’t see anything relating to PXE in recent changes. Ran it anyway to bring it current. No changes in PXE boot behavior.

@george1421 Ran a capture job before I left Friday using the FOSLinux usb boot method. Checking the deploy sometime today.

As always, thanks for you help you two!

@tandersb the date is a nice to have feature and is not indicative of an issue. In particular the master node has a service that updates the sizes. To get the date, the image is updated once the capture task is completed. This, however, does not mean there is (or isn’t I suppose too) a problem with the image. Are you having issues using it?

And everything works!! Thank you for help!