@george1421 Thanks a ton for those words (OK that iso image seems to be only a legacy/bios boot media.)

I figured out one thing I was doing very wrong.
I was PXE booted in UEFI… when hitting F12 to boot the PC, I automatically selected the IPV4 under UEFI, and not the “network boot” under legacy, both of which show up in my F12 menu. Both of which FOG PXE boot works with.

Well, after using the legacy, the dell iso image (that only shows CD.txt) works flawlessly. Now I think everything will work that requires legacy for me, as some things seems you can’t use PXE UEFI with (perhaps not supported by the manufacturer, some programs like Memtest require spending thousands of dollars to get the “site edition” that works with PXE, etc). Keeping in mind your words in other posts about the size limitations of isos (2gb?), the ones I wish to use should all be small enough. I think we can mark this as solved.

Thanks so much for your help.

HI @Sebastian-Roth Sebastian, yeah sorry about the double submission it was by accident. I will sent you the details that you requested soon. thanks

@typotony Sorry I’m late to the party.

I haven’t built a “helper” command yet for removing fog images, but I do have Get-FogImages

https://fogapi.readthedocs.io/en/latest/commands/Get-FogImages/

If you setup the fogapi powershell module, you can use that to get a list of the current images.

You can delete the records of the fog images from the database via

Remove-FogObject

i.e. this would delete ALL your images

$images = get-fogimages $images | Foreach-object { Remove-fogobject -type object -coreObject image -idofobject $_.data.id }

That little snippet is untested but should be enough to get you started.

I’m pretty sure the api command won’t remove the files from the server though.

However, I believe the path to the files, or at least the relative path is in a child property of the data property when you run Get-FogImages.
So if you set this up to run on the linux based fog server using the powershell api module, you could script something that runs in a cronjob to delete from the database and then the files.

i.e. (again untested as I’m away from my test environment, so the property names are guesses, but it should point you in the right direction)

Get-FogImages | % { if ($_.data.name -eq "removeMe") { Remove-fogobject -type object -coreObject image -idofobject $_.data.id rm -fr $_.data.path } }

This, if run on the fog server where you have configured the fogapi module (see my signature for doc links), would find images named “removeMe” and then delete them from the database and then the files from the server.

@pastorn said in help with multi-cast deploy:

the DHCP is on windows server 2022

Can you please post pictures of the settings?

Hi,

I just rebuilt two proxmox debian 11 containers with FOG 1.5.10

Master node > install HTTPS
Storage node > install HTTPS

Install plugin Location

Master node and storage node are in the default storage group
Master node > default’s Master node

Create new location > location_1
storage groupe > default
storage node > defaultmember
storage node protocol> HTTPS

Create new location > location_2
storage groupe > default
storage node > secondary node
storage node protocol> HTTPS

Create snapin in default storage group with replication enabled

Configure one host with location_1
Deploy snapin > OK, it works

Configure one host with location_2
Be sure the snapin is replicated into the storage node
Deploy snapin > it doesn’t work
What am i doing wrong ?

Here is the snapin log

---------------------------------SnapinClient--------------------------------- ------------------------------------------------------------------------------ 03/07/2023 12:39:24 Client-Info Client Version: 0.13.0 03/07/2023 12:39:24 Client-Info Client OS: Windows 03/07/2023 12:39:24 Client-Info Server Version: 1.5.10 03/07/2023 12:39:24 Middleware::Response Success 03/07/2023 12:39:24 SnapinClient Running snapin snapin_1 03/07/2023 12:39:24 Middleware::Communication Download: https://xxxxxxxx//fog/service/snapins.file.php?mac=00:23:24:19:46:64&taskid=2 03/07/2023 12:39:24 Data::RSA ERROR: Certificate validation failed 03/07/2023 12:39:24 Data::RSA ERROR: Trust chain did not complete to the known authority anchor. Errors: La signature du certificat ne peut pas être vérifiée. (NotSignatureValid) 03/07/2023 12:39:24 Middleware::Communication SSL certificate chain error: Une chaîne de certificats a été traitée mais s’est terminée par un certificat racine qui n’est pas approuvé par le fournisseur d’approbation. 03/07/2023 12:39:24 Middleware::Communication ERROR: Could not download file 03/07/2023 12:39:24 Middleware::Communication ERROR: La connexion sous-jacente a été fermée : Impossible d'établir une relation de confiance pour le canal sécurisé SSL/TLS. 03/07/2023 12:39:24 SnapinClient C:\Program Files (x86)\FOG\tmp\file.zip 03/07/2023 12:39:24 Middleware::Communication URL: https://xxxxxxxxx/fog/service/snapins.checkin.php?taskid=2&exitcode=-1&mac=00:23:24:19:46:64&newService&json ------------------------------------------------------------------------------

@smazzola We need more information to be able to help. Please provide what has been asked or we’ll close this topic.

@Warsonix I really needed to get those laptops imaged asap, so I just used a USB-C to Ethernet adapter on those and it worked. I haven’t touched those laptops since then.
Funnily enough, I have to re-image them next week, so I’ll let you know what happens.
I have done a lot of changes to my FOG server since then, so it’s really going to depend on your setup too.

@tahitiju said in Multicast is very slow:

I try to deploy an image to some PCs but performance is very low (2MB/min) using multicast.
For the purpose of the test, FOG server (1Gb NIC), clients (1Gb NIC) and dhcp are connected together using a Linksys Switch ( 16 x 1Gb ports / unmanaged) .
Using unicast, performance seems normal (~1,5GB/min deploying 14 PCs).

A few things jump out at me with this. Multicasting can be very taxing on inexpensive network hardware. When you are getting 2MB/min how many systems are you multicasting to? Do you get the same performance when multcasting to 1 or 2 machines?

Multicast imaging moves at the speed of the slowest computer in the mcast group.

1,5GB/min is on the slow end of the scale. On a well managed 1GbE network, imaging to current hardware, I would expect about 6GB/min. If put your fog server on 10GbE network I would expect about 13GB/min. I’m only pointing it out that there might be something in your network infrastructure that is slowing things down.

A 1GbE network link will saturate with 3 simultaneous unicast deployments.

The FOG performance numbers displayed on the target computer are a composite number of how fast the fog server can pull the image off the disk, send it over the next, the client receiving the image, expanding it in memory and then writing it to disk. Any one component that is slow will impact the overall performance score.

@Tom-Elliott

It’s every device we’ve tired. We’ve tired both UEFI and MBR. iPXE booting is working with everything else we have and is able to utilize the NIC just fine.

Dropping down to the CLI, the OS can see and list the mac addresses just fine. It appears that it’s just however FOGs init/boot is looking at or for the MAC address is the issue.

@george1421 thank you very much

@Noseman The tools used within FOS (FOG OS doing all the hard work when capturing and deploying) are no official Microsoft certified software products but from open source community. They work in 99% of cases but I can imagine there can be special states of the filesystem or certain edge cases those tools simply cannot handle (yet).

Great you found a workaround!

@wass Since all of the boot loaders you mentioned are bios boot loaders and you are seeing the no configuration methods succeeded it sounds like the computer is in bios mode. Its strange that iPXE and bios mode computers are not able to configure the interface. For bios the boot loaders undionly.kpxe or ipxe.kpxe should work on 99.8% of all computers. Does this computer have multiple nic cards?

@kamburta Pretty sure this is known and fixed in the dev-branch versions of the FOG repository.

@repier89 Nice you got that external NIC adapter to try and see if it’s a network issue or now. And yes, we have a winner. 😉

Please schedule a debug deploy task for the HP Probook 450 G9 and boot into it. Run lspci -nn | grep -i net and post output here.

@Sebastian-Roth @rodluz

Thanks so much for the info, guys!

@Almeida I suggest you update to 1.5.10 or at least manually update the FOS kernel.

@KaiHerlemann Yes, @JJ-Fullmer is right there. The installer is not made to handle custom certificates properly yet. We never found the time to make this work reliably. But if you are good with managing this yourself you can still do it.

The whole topic is a bit complex due to the different tools and layers involved.

Basic web access to the web UI - just adjust Apache config as you like But along with that the iPXE boot loader is using HTTP/HTTPS to load the menu items. So if you switch to HTTPS you also need to compile your own iPXE binaries - not very hard: https://docs.fogproject.org/en/latest/development/fog-release/#ipxe (but use ./buildipxe.sh /path/to/your/CAcert.pem and skip the armsupport=1 if you don’t have ARM CPUs) Now this was the easy part. I started to write about the fog-client here but then realized I did so in the wiki already: https://wiki.fogproject.org/wiki/index.php?title=HTTPS#Custom_CA_and_certificates

I know, this is not ideal having to stich together the pieces from various sources and make up the rest yourself. So if you are keen we would appreciate if you document exactly what you do and we’ll add it to the official documents. That would be really great!

@KaiHerlemann said:

Usually we use ACME to create certificates.

I would not setup a FOG server open to the public. There are ways to get certificates through ACME without facing it to the web, e.g. opening ports only for the time of cert renewal on the firewall, doing cert renewal on a separate machine and copy those over and so on. Please consider wisely because FOG is not made to run on a public IP/hostname safely.

@JJ-Fullmer said:

I would suggest at install time NOT selecting ssl and then altering the config to use your custom certificate.

In the one hand I agree. Doing it this way you can go step by step. On the other hand if you do a fresh install (don’t if you have a running server) then I tend to suggest you enable SSL straight away because it will generate a SSL enabled Apache config for you and save you some time.