@sebastian-roth
Thank you.

I saw that the printers in the list of a group are all printers not the assinged.
In the client there are the right ones.
thank you

@george1421 I must have missed the other persons post, this is my only post about it. Thanks for the info and I will check out that article

@george1421 OK I see, and thanks for that!

I went through the dirty bit and realised Sysprep was the issue in hand, as it was re-imaging over the same sysprepped image which seems to cause issues with cloning.

Removing the bit didn’t seem to work, so I then had to completely re-install a fresh Windows and start over again, and ran sysprep and fog cloned it successfully.

I see why using VM would be easier as you can sysprep as many as you need etc.

Thanks!

@wt_101 I do have a proof of concept for NFSv4 and I’m running it on one of my production FOG servers. https://forums.fogproject.org/topic/14791/feature-request-for-fog-1-6-x-configure-image-capture-to-use-nfsv4-instead-of-nfsv3/10

The tough spot is that you need different inits with NFSv4 enabled. The default inits that come with FOG have nfsv4 disabled. The other issue with nfsv4 is that the shares are changed a bit into a virtual share. My PoC thread also covers that. I really need to consolidate that into an easy to follow thread. I was going to save pushing for nfsv4 in FOG 1.6.x series but that series is getting pushed out because of the lack of dev time. Here are the inits from Jun 2021 with nfsv4 enabled: https://drive.google.com/file/d/1EHLhmM9-kXpFO7kfk3H1ydEZF3q8lID1/view?usp=sharing

I have found the correct file to change which is “pdodb.class.php”

Cert to add here
6fe5af73-ef3f-4cad-a605-3da5c1c0eca4-image.png

While the port can specify at $dsn
a83bd0c8-cc7c-4f80-bdd2-679fe4221514-image.png

@forcom5 Well we typically see this with older hardware. It looks like thise 280 G1 systems have a 4 gen processor in them, so that makes me think they are on the older side. BUT if you have a working solution, run with it.

@george1421 …having made my decision though, I have seen the REFIND option available in the Boot Exit Settings. I’ll drop back in if that fixes the universe in the more “legacy” approach to all this.

EDIT - it did not I got a snowstorm of odd characters marching across the screen. Quite pretty but not successful. All fine though, have my route to making this work now.

In the BIOS on the configuration tab, disable Intel VMD Controller and disable Secure Boot on the security tab. This is the only way i’ve gotten this to image.

@dminga Let me ask a few questions to get the full picture:

Which version of FOG did you install? Which OS and version do you capture and deploy an image of? Is the image set to resizable or non-resizable? Is the disk captured from larger than the disk you want to deploy to?

@sebastian-roth said in Image Capture database error:

Please check the Apache and PHP-FPM logs to find out what’s going wrong

Thanks. Will do.

@wt_101 I can tell you that multicast is more problems than unicast. Multicast requires more resources (things setup correctly) than unicast.

The way fog works is that the udpsend (multicast sending program) is launched by the web server. So multicasting is linked to the server where the web ui is running. The storage nodes do not have a web ui. So the key here is that multicasting is started by the FOG web server.

It is technically possible to launch a program on a remote linux server using ssh. This requires ssl certificates to be put in place so that the ssh connection uses certificates instead of a password.

A storage node is technically a normal fog server except it uses the master node database and the web interface is shut off from browsing. The web interface is there, its just blocked from access. So the udpsend program should also be installed, so it could send out multicast images. FOG isn’t designed that way, but its not impossible to do if you had the motivation and php programming skills.

The last thing I can think is if:

The FOG API can be called on a “Storage node” AND You can schedule a multicast deployment via the API

You could make a curl call from the master node to the storage node to initiate a multicast deployment. I’m only mentioning this because it might be possible, but I have not tried to know if it IS possible to do.

So to recap I see 3 ways to get a storage node to multicast.

Use ssh and call udpsend directly from the fog server Write a custom php page on the storage noted that would launch udp send based on a web page call that passes the required parameters. Use the FOG API to call a multicast send on a storage node.

I can’t tell you if any of these methods will work. I can only tell you that the sending of multicast image is tied to the FOG Web UI.

@sebastian-roth I will install those inits tomorrow. I got confused on the inits due to all of the other files in that repository, in hindsight a lot of it is hash check files. Again, kind of new to all of this. I really appreciate all of your assistance.

@george1421

Best post I’ve found in troubleshooting this thanks much for that George! Tracked down another pesty, ancient server that “answered” and I will chop it momentarily.

I’ve had some excellent and patient help from you over the years thanks muchly for what you do mate. 🙂

@george1421 Okay Thansk for the Info. I will test a bit and give feedback if the thread can be marked as solved.

@kvothe88 I suggest you compile iPXE from the latest source code and try again: https://docs.fogproject.org/en/latest/reference/compile_ipxe_binaries.html

@lanius said in LenovoT14sGen2 Cannot Get Image:

This update has solved my problem

So just for clarity updating your FOS Linux kernel to 5.15.x fixed imaging on your Lenovo T14 Gen2?

@nw22 I forgot to ask which version of FOG do you use? Specifically which version of the FOS inits (when it boots up it prints the version just below the ASCII art FOG logo)?

Would be great if you could do some testing when we do find and fix stuff. Are you available for testing?

@ayy_nelson said in PXE boot issue with HP Probook 450 G8 (Realtek Nic):

I too purchased a handful of new G8 HP Laptops.

Some things we found with this new generation of systems with this realtek network adapter. Update your FOS Linux kernel to 5.15.x series (we just discovered this) and also update your iPXE version using this method. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

Right now we only have anecdotal evidence that it fixes what changed in this generation of hardware.

@akaushansky said in HP Elite X2 G4 imaging stuck on rEFInd:

BUT, creating bootable USB with 0.11.00 version worked. the very same rEFInd.efi and conf work on USB and dont work on FOG…

It’s not FOG itself causing the problem but the same binary being loaded and run in a different way. Loading it the PXE boot way seems to cause trouble on this particular hardware.

Have you updated the UEFI firmware to the latest version? Have you updated iPXE to the latest version?

No promise this will help but it is worth a try.