@yeet The startech adapter is not supported by your HP firmware.

So that startech adapter is an external usb to ethernet adapter, right?

Since the HP uefi firmware doesn’t show that startech adapter as bootable, the built in PXE roms will not work. So instead of using the onboard PXE roms, we can load FOG’s iPXE from a usb flash drive. Once iPXE is loaded then imaging happens normally.

How the boot order goes is this:
(UEFI) PXE ROM -> downloads and launches iPXE -> downloads and launches bzImage (FOS Linux).

So if the pxe roms don’t work we can just launch iPXE from a usb flash drive and hope that iPXE has the drivers for the nic built in.

If iPXE won’t configure that startech adapter, then you can skip iPXE and just load FOS Linux on the usb stick and not use iPXE.

The reason why I said USB-2 network adapter is that the older the adapter is the better the chance that both iPXE and FOS Linux will have a built in driver for it.

@tom-elliott
Normally I always disable TPM and Secure Boot before Imaging a machine - whether Capture or Deploy.

The fact that TPM wasn’t in the BIOS got me started on this, and disabling TPM worked like normal when the PS commands were run.

The issue with that command - I just ran it on the machine I Deployed to. BitLocker was never enabled - I get this error:

ERROR: An error occurred (code 0x80310008): BitLocker Drive Encryption is not enabled on this drive. Turn on BitLocker.

Looked at BitLocker through Control Panel? Turned off.
Right-clicked the <C: > drive in “This PC”? Asks if you want to Enable it.

That’s why I was looking for TPM and not BitLocker.

EDIT:
I know I said “machine I Deployed to”. I didn’t have BitLocker enabled on the machine I Captured - my fix was disabling TPM.

@sebastian-roth

Once I setup a bridged virtual network adapter for the vm within the
KVM Virtual Machine Details, I was able to make everything communicate.

Issue Resolved. 🙂

@sebastian-roth Obviously!
We had a bad factory BIOS setup and didn’t think about looking into more detail … our fault!
Thanks a lot for your help, from the outside the problem is often more quickly identifiable;)

@ewojcik said in Missing QLogic FastlinQ driver:

Thinking long-term sustainment, are there user methods for getting additional firmware (or drivers) built in? I found the wiki instructions for building custom kernels but those don’t cover additional firmware blobs.

Sure, good point. Unfortunately the wiki has several articles on kernel buildung and some are very dated. As well you are right, even the latest one does not include information on how to add binary firmware blobs: https://wiki.fogproject.org/wiki/index.php?title=Build_TomElliott_Kernel#Build_TomElliott_Kernel_for_FOG_0.33b_and_newer

I’ll give you the hints here in the forum and will add this to the wiki soon:

Follow the steps in the wiki article up where it says you should run make menuconfig or make oldconfig. Now either edit that file manually, search for CONFIG_EXTRA_FIRMWARE, simply add the relative path of the firmware blob you want to that line (separated by spaces) and run make oldconfig or run make menuconfig, navigate to Device Drivers -> Generic Driver Options -> Firmware loader and edit the second option starting with (bnx2x/... (a list of files) Save config and build the kernel

We are also working towards updating all the documentation (wiki) and move it to readthedocs. You are very welcome to help if you like.

@george1421Nothing changed, reinstalled 1.5.7. Sorry for the delay.

@redbull007 Understood not fog. But where in the process is it failing.

PXE Rom requests dhcp address
PXE Rom DORA sequence where it gets the boot server and boot file
PXE ROM downloads the boot file from the boot server
iPXE starts up
iPXE Requests dhcp address.

If its in the iPXE then I thought of a test we can do

The tcpdump from the fog server point of view will tell us what the target computer is exactly asking for. That is the logic why to use it there. The test gives the best details if the target computer and fog server are on the same subnet to grab the packet capture.

@cyannella Hmmm, its been a while since I looked at that. It still should be technically possible to do.

@george1421
Hi George!
I wanted to circle back and let you know that all is working now thanks to your help.

I have some other questions but I will open new tickets for those.
This crisis is complete and working now. I was able to boot one of the tablets
and gather an image off of it.

Thank you soooo much for the help.

Chris

@sebastian-roth
Ok no problem thank you for you response
I open a new post

@george1421

So I ended up building a new FOG server and this time everything worked as it should. Not sure what was causing the old server to act that way, but even after manually downloading and saving the new files, it still showed the old version.

Anyhow, thanks for your guidance with this.

Rocky

@sebastian-roth After calling Dell support, it seems there was something wrong with the laptop that was being used to test. I re-configured the UEFI to defaults, purged the default config of RAID to AHCI, and have rebuilt my images using the smaller drives on the newer laptops.

I am now able to capture and deploy as expected. Thanks to everyone for your assistance with this! We can consider this thread resolved.

@quinniedid Ok, looks like this is not due to the picture you used but a general issue with displaying the image on the HP ProBook 445 G2. So far I have not found any hint on other people reporting this issue to iPXE and I would suspect this to be kind of an endeavor to figure out even with the help of iPXE developers. Though you can still report it on github or the forums.

The easier way is just using the workaround that George came up with. Not fancy but way less effort than figuring this one out I suppose.

@olsen Yes that is what I was thinking of. Read over that document and understand the caveats. Look at the fog forum chat bubble for a few more hints to get you a jump start.

@cmurray139 I’m going to close one eye and squint with the other to read between the lines here…

I read this as: I have a fog server on a dedicated imaging network. This server has no connection to the outside world. I just purchase new hardware that I can’t image because the FOS Linux kernel is too old. How can I manually install the later version of the FOS Linux kernel that supports my new computers?

If I guessed right then you need to get the kernels from here: https://fogproject.org/kernels/ Download Kernel.TomElliott.5.6.18.32 and save it as bzImage32 (watch your case) and Kernel.TomElliott.5.6.18.64 save it as bzImage. Now move these to the FOG server into /var/www/html/fog/service/ipxe directory replacing the files in that directory. You might want to rename the existing files just in case you need to back track to the older kernels. Now just pxe boot the target computers and see if the updated kernels do what you need.

Now I also have to say since you specifically called out storage devices on these target computer, go into the bios (firmware setup) and make sure that the disk controller mode is ahci and not raid or raid-on. This will cause all version of the FOS Linux kernel to not be able to detect the storage device behind the disk controller.

@george1421 Thanks, for the support, resolved

@sebastian-roth Ah, my bad. I did not see that previous post. I tried snponly.efi, deploying works fine now. Thanks a lot!

@george1421 Thanks, After downloading the more recent kernel since it worked, I proceeded this way because I encounter problems directly via the server interface.
We can now use fog on our newer machines.👍

@sebastian-roth said in Can't multicast on latitude 3310:

more I think udp-receiver is actually dying at this stage and not delivering the rest of the data.

What if we are running out of memory on FOS Linux partition. Where we bumped it up from 127MB to 275MB for the larger inits? This 3rd partition isn’t that large though. My C drive partition is 25GB, but I rarely multicast while imaging. I do remember we had to make the FOS Linux drive for one user before we upped it to 275MB but I can’t remember the circumstance.

Something else we need to be mindful of / is this is an untested image from the perspective of multicasting. This is the first uefi image to the first uefi target computer the OP has. The previous ones have all been bios based.

If I remember correctly when the multicast task starts, it actually spins up one udpsend task for each partition. I wonder if that task is terminating on the server not the target computer. But again why only for uefi systems…

I need to update the storage nodes, how are they updated? the Web Master updated it and it worked correctly