@Jim-Graczyk
Re-reading through your post I realized you mentioned a fresh install of the client isn’t working.
There may be a different issue. When I migrated from centos 7 recently I ended up rerunning the fog server installer with --recreate-ca --recreate-keys and reinstalled the fogservice on all my clients to have them use updated certs and an updated fog server name. I didn’t have the time to troubleshoot it and I also don’t have 8 locations so this wasn’t that big of a thing to deploy via other software deployment tools we have.

In theory you should still be able to migrate the private and public keys (note that the private keys are hidden with a prepended . in the filename when you migrate them from the old fog server.

@Jim-Graczyk Firstly, are you running 1.5.10 on the new server or 1.5.10.1615 the latest stable release version? Granted it would be best to have updated the old server first and then migrate so you’re migrating between the same versions.

If you maintained the same server name (or at least used a dns alias to point the old server name to the new server name) and you migrated the /opt/fog/snapins/ssl directory and all other fog stuff (like the database and the /opt/fog/.fogsettings file) before running the installer for the first time (you may be able to throw them in there afterwords in theory)
then you would have the same CA cert and private cert and subject name for the public cert. So if all that PKI stuff remains the same then all your hosts would already trust the fog server ca (it gets added to trusted root certs when installing the fog client) and the public cert should be updated on the client or may even remain the same. Sounds like you’re using a dns alias so as long as that is updated in the migrated locations it can be made to work.

If you ran the install of the new fog, and then migrated stuff, then you might have some conflicting settings and you’ll have generated a new Fog CA with a new private key for the web server certificate that the fog client uses to ensure you’re communicating with the right fog server.

Granted, making a new CA and private key when migrating servers is a good idea and with a new CA it’s easiest to re-install the client to fix the issue so it gets the new CA and cert.

I believe you could do something like this in an admin powershell session to force the fog service to use a new CA.

#stop the service
stop-service fogservice; 
# delete the certs from the fog service program files path
remove-item "C:\Program Files (x86)\fog\ca.cert.der","C:\Program Files (x86)\fog\fog.ca.cer","C:\Program Files (x86)\fog\tmp\public.cer"; 
#remove the old Fog CA cert from the trusted root store
Get-ChildItem Cert:\LocalMachine\Root\ | Where-Object Subject -match 'CN=FOG Server CA' | Remove-item -force -ea 0;
#Download the new ca cert, replace "fog-server" with your fog server's name
iwr "https://fog-server/fog/management/other/ca.cert.der" -OutFile "C:\Program Files (x86)\fog\ca.cert.der"
#trust the new CA
import-certificate -FilePath "C:\Program Files (x86)\fog\ca.cert.der" -CertStoreLocation Cert:\LocalMachine\Root\
#reset the host encryption in the gui (or if you use my FogApi powershell module you can use the Reset-HostEncryption command)
#after resetting the host encryption start the service back up
Start-Service FogService;

I just ran all that on a working client and it connected. I even stopped after removing the ca cert from the store and files to confirm that broke the client. Then imported it again and all was well. It’s possible that resetting the host encryption isn’t needed, but I imagine it’s needed as you have a new private key, etc.

Granted, reinstalling the service should do all of the above, so it may be a null point.

You could also restore the old CA cert and private key from where you’re migrating to and you may be able to make it work without touching the clients besides restarting the service and resetting host encryption.

@Tom-Elliott It sounded like he tried snponly and others in an earlier post.
The initializing devices happens after the efi file is downloaded and booted to, secure boot would stop it from booting because it’s the efi file that isn’t signed.
I’ve had some luck with the delay based ipxe files on troubleshome devices like this, though there also could just be some driver missing from the ipxe build that isn’t initializing for this device. I feel like it doesn’t boot to pxe at all if the ethernet adapter isn’t supported.
@anube The other thing I’ve had luck with is booting directly to the ipxe.efi file. But on a new device that requires either the device to have a built-in uefi shell or you

• setup 2 usbs
  • 1 a refind usb boot disk
  • 2 another usb where you have the efi boot files from /tftpboot (I usually just grab the ones I know work but you could just grab all of /tftpboot via winscp/filezilla/or some other ftp client off the fog server).
    • I would also go here https://www.realtek.com/Download/List?cate_id=584 and download the UEFI UNDI driver. Extract that and grab the x64 RtkUndiDxe.efi file and throw that on the usb too.
• Then you boot the refind usb,
• choose the uefi shell option
• find the usb with the tftpboot folder and efi driver.
  • To find it in the uefi shell you switch to each disk like fs0: then enter, then run ls to see if it’s the right disk, then fs1: fs2: etc.
• Once you find it you can run load RtkUndiDxe.efi hit enter so the latest uefi driver for that adapter is loaded.
• Then find the efi boot file you want to use/try a bunch of them. i.e. /tftpboot/ipxe.efi simply entering the path will boot to the efi file and it will attempt to then boot to the fog server.

If that does the trick you at least have a workaround and a simpler way to find which efi boot file works for that device. It may be possible to load the updated efi driver into the firmware, but that varies by device and I wouldn’t suggest it unless there’s an official way of doing it provided by MSI. It may also work with an older build of ipxe or a future one or there may be something that can be added to the ipxe build. You can also find ways to make this methodology more automated.

@Eliseu What I see here is that ipxe is booting, but this isn’t FOG’s version of iPXE. Are you running this pxe booting computer in virtual box?

@stokehall Just a quick oracular review and it will eventually ship with linux kernel 6.11, and it kind of works with the latest ARM processors. But we are getting close and kernel 6.11 is probably a good place to start. We might want to start with the default config for the qualcom processors and then add in the bits that FOG needs. Linux kernel 6.11 was released on 15-Sep.

@anube Have you tried the 10sec-delay versions of the ipxe files?

@adam1972 said in Linux host name change after imaging?:

There’s nothing in AD

That checkbox at the bottom of AD is where you enforce hostname changes I believe. Which I just noticed is also what @Tom-Elliott said 20 minutes ago.

I would also look at the snapin definition, this screenshot is from 1.6, but these boxes still existed on snapin definitions in 1.5 (minus the No action, it’s just checkboxes for shutdown or reboot I believe)

If those are checked it could be part of why it’s doing so many reboots.

The fog client runs things in windows without being logged in, there’s actually 2 services running for it, a system service and a user service, I imagine linux works the same way.

However, if it’s waiting to perform the hostname change, there could be something else that’s causing a reboot at the linux OS level when the hostname is attempted to be changed without a reboot? If that is waiting to happen I believe the client waits for that to finish before attempting snapins. It causing the random restarts is still perplexing.

@jfernandz Actually bitlocker fde (full disk encryption) was developed to prevent what you are trying to do. I don’t remember if the developers put a stop point in the code if fde is detected but technically FOG will copy a bitlocker protected disk, but it will do it in raw mode. The issue you will have if fog cloned the disk image is that bitlocker encrypts the disk with a key that is held in the TPM chip. So even if FOG cloned the disk, the data would not be able to be used because the TPM keys would not match. This prevents cloning or accessing data on protected media.
For the data to be cloned and usable afterwards you must decrypt the drive before cloning.

@fairoozfarhan You didn’t mention what you are trying to do with the swiss army knife called dnsmasq. If you are trying to configure a proxy dhcp server the configuration listed in this tutorial will get you started: https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server If you want to use that dnsmasq server for a dhcp and or dns server you need a bit more data in your configuration.

Usually when dnsmasq fails to start there is a service already using a port it needs to start. Like DNS or DHCP. There may be a log file in /var/log

@Eazis said in Multicast stuck:

[09-18-24 9:36:35 am] Interface not ready, waiting for it to come up: 10.54.68.101
[09-18-24 9:36:45 am] Interface not ready, waiting for it to come up: 10.54.68.101
[09-18-24 9:36:55 am] Interface not ready, waiting for it to come up: 10.54.68.101

I think this is the most interesting bit of info. Why would udpsend wait for an interface to come up that is clearly up. In the global configuration make sure the proper interface is defined for the imaging interface. Also there may be an interface section in the multicast section of the configs. I don’t have a fog server near me at the moment but it should be under fog ui->fog configuration->fog settings. Hit the expand all button then search for multi

Also when you schedule the multicast deployment from the fog server console run ps aux|grep udpsend and save the output. I think part of the udpsend command parameters will also list the interface udpsend is using.