@george1421 Yes it is. Both, the fog server and the host device, are in VirtualBox - and i get the error message.
But tbh if the problem doesn’t show up when deploying the whole system in my network, i can live with the error occurring in VB.

If it’s true that this only happens in VB and not on the actual network (and then Toms solution works), then this issue is resolved for me.

@Sebastian-Roth Sadly I have not actually done this.
I believe that it is possible and @tom-elliott may have some insight on accessing the api over https. I believe he has some forum posts elsewhere discussing it. I think there may be some fog server side configuration needed to enable https api. For sure you need to have the root CA certificate that issued your fog server web certificate trusted on the machine issuing the commands. In theory that should be all there is to it, but I haven’t done a ton of testing on it, and while it’s on my to-do list, it’s a bit far down the list. Not to say SSL/TLS isn’t very important even behind a firewall, I just haven’t got there yet.

@glequeau In theory, if you can get all the certificates trusted correctly and can access a fog api url in a browser over https, then it should work for the powershell commands as well. That’s how it typically works with powershell and api commands.

That was long, here’s a short version:

Go to your https fog site view the certificate being used and view the trust chain Download the root and any intermediate CA certificates Install them on your machine as trusted root ca certs Try the api commands again with the https url set

If that doesn’t work, then we just have more development needed on https api commands

You could also try editing your locally installed version of the fogapi module. Specifically the invoke-fogapi command (probably at C:\program files\windowspowershell\modules\fogapi\2303.5.33\fogapi.psm1) then search for that command in the compiled version of the file.

You would add the -SkipCertificateCheck switch to all calls to invoke-restmethod and invoke-webrequest which would bypass that error and still use the ssl connection, but ignore errors about untrusted certificates

Thanks for the advice. Ran into a speed bump along the way. When I was doing step 3 I got an error about PHP 7.4. I upgraded to PHP8.1 and then was able to install the upgrade for Fog. After that I did the Ubuntu upgrade and the system didn’t come up so I followed your advice and re-installed Fog and I am up and running!

Thanks a lot @rodluz !

I took your script and adapted it. I use it directly on my FOG server, which simplifies things a bit. I also changed the mail to a notification sent to my smartphone with ntfy, which I find easy to use.

I also mounted my NAS share in NFS directly on /mnt/FOGBackups.

Here’s my script:

#!/bin/bash fogServerAddress="172.X.Y.Z" # Change to actual FOG server address backupDate=$(date +"%Y%m%d") backupDir="/mnt/FOGBackups/$backupDate" backupDirImages="/mnt/FOGBackups/images" snapinLocation="/opt/fog/snapins" reportLocation="/var/www/fog/lib/reports" imageLocation="/images" failedBackupDB=0 failedBackupSnapins=0 failedBackupReports=0 failedBackupImages=0 [[ ! -d $backupDir ]] && mkdir -p $backupDir/{mysql,snapins,reports,logs} >/dev/null 2>&1 [[ ! -d $backupDir/mysql || $backupDir/snapins || $backupDir/reports || $backupDir/logs ]] && mkdir -p $backupDir/{mysql,snapins,reports,logs} >/dev/null 2>&1 backupDB() { wget --no-check-certificate --post-data="nojson=1" -O $backupDir/mysql/fog.sql "http://$fogServerAddress/fog/management/export.php?type=sql" 2>>$backupDir/logs/error.log 1>>$backupDir/logs/progress.log 2>&1 stat=$? if [[ ! $stat -eq 0 ]]; then echo "Failed to backup database!" failedBackupDB=1 else echo "Database backed up." fi } backupSnapins() { cp -r $snapinLocation $backupDir/snapins/ 2>>$backupDir/logs/error.log 1>>$backupDir/logs/progress.log 2>&1 stat=$? if [[ ! $stat -eq 0 ]]; then echo "Failed to backup snapins!" failedBackupSnapins=1 else echo "Snapins backed up." fi } backupReports() { cp -r $reportLocation $backupDir/reports/ 2>>$backupDir/logs/error.log 1>>$backupDir/logs/progress.log 2>&1 stat=$? if [[ ! $stat -eq 0 ]]; then echo "Failed to backup reports!" failedBackupReports=1 else echo "Reports backed up." fi } backupImages() { rsync -auv $imageLocation $backupDirImages 2>>$backupDir/logs/error.log 1>>$backupDir/logs/progress.log 2>&1 stat=$? if [[ ! $stat -eq 0 ]]; then echo "Failed to backup images!" failedBackupImages=1 else echo "Images backed up." fi } checkForFailures() { echo "Running checkForFailures()" if [[ $failedBackupDB -eq 1 ]]; then message="$message \nFailed to backup database." fi if [[ $failedBackupSnapins -eq 1 ]]; then message="$message \nFailed to backup snapins." fi if [[ $failedBackupReports -eq 1 ]]; then message="$message \nFailed to backup reports." fi if [[ $failedBackupImages -eq 1 ]]; then message="$message \nFailed to backup images." fi } sendNotif() { echo "Running sendNotif()" if [[ ! -z $message ]]; then { curl -d "FOG Backup Failed\n $message" ntfy.sh/XYZATEHFJICH } else curl -d "FOG Backup Successful!" ntfy.sh/XYZATEHFJICH fi } backupDB backupSnapins backupReports backupImages checkForFailures sendNotif

@Trep76470 A windows dhcp server should work just fine. Is it OK to guess that your fog server is at ip address 192.168.21.220?

The error message you first posted usually indicate a bios computer booting, but I don’t know leovo computers pxe boot process. Typically uefi computers would mention NBF.

Are the pxe booting computers, dhcp server, and FOG server on the same IP subnet? If yes then we can use tcpdump running on the FOG server to capture what is actually flowing down the wire.

Some things to check on your dhcp server.

Make sure it is responding to both dhcp and bootp requests. Both bits of information need to be in the dhcp OFFER packet. If you have redundant dhcp servers, make sure you configure dhcp options 66 and 67 on both servers. Microsoft’s HA for dhcp does not copy over these settings.

If you can not find the solution then I have a tutorial here: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Look at the results with wireshark, specifically the OFFER packet. Look to see what dhcp servers are responding to the offer packet. Then in the offer packet look at the ethernet header. You are interested in the next-server and boot-file fields. They need to be populated and match the dhcp options 66 and 67 under the dhcp options section. If you can not understand what you see in the pcap file, then upload it to a file share site and then either post the link here or DM me using fog chat the url and I will look at it.

hey guys
Is it possible that the Subnet Group Management plugin automatically places a location on a new host that was done through quick registration and inventory using the subnet that this host is on?

@Tedamp Just to add to this topic: FOG does not mess with the EFI boot loader entries. You have to do this yourself. You might wanna read this topic as well: https://forums.fogproject.org/topic/16703/dual-boot-2-disks-unable-to-boot-grub/2

@FlareImp said in Showing Last Check-in Time:

dumb question but where would I find the log file for hooks?

See my signature.

Bonjour,

quel est le serveur dhcp ?

To set up an IP helper on your Aruba switch, you can follow these steps:

Log in to your Aruba switch using an administrator account.

Navigate to the switch’s configuration interface.

Find the DHCP configuration section and locate the IP helper settings.

Add the IP address of your FOG imaging server to the IP helper configuration.

Specify the VLAN that the PXE boot requests will be sent on, which in your case is VLAN 100.

Redirect the PXE boot requests to the management VLAN, which in your case is VLAN 4.

Save the configuration and restart the switch if necessary.

To ensure that only PXE boot requests are redirected to the imaging server, you can configure the firewall rules on the switch. You can create a rule that only allows PXE boot traffic to be forwarded to the IP address of your imaging server.

@Milheiro Zstd level is compression level right? That I’m aware of. Makes sense if you increase compression that it would take longer to capture/deploy. What I was experiencing was linux kernel level errors, only when deploying to a virtual disk that resides on the xenserver’s local storage array. I wonder if it is something like Truenas where it performs worse when you let the storage controller handle the array vs a soft-raid controlled by the OS.

@george1421 @Tom-Elliott
thank you for your answers.

@george1421 i try your solution and is start ! thank you

After turning off the firewall on my Ubuntu VM, the install finally worked. I will close this thread and look into the correct firewall configuration.

@ordinatous said in VM won’t boot from PXE on proxmox:

@JJ-Fullmer
Yes FOG on esxi , but I’m sure it’s not the problem.

I’m not saying it’s a problem, it’s a great way to host your fog server. I was suggesting making your VM to capture from on esxi instead of proxmox.

I try to run the script as snapin
But I get no c:\temp\firmware.txt file
I think the script is not executed

Here is the command line viewed on the fog console:
powershell.exe -ExecutionPolicy RemoteSigned -NoProfile -File boot-uefi.ps1

I get this log

------------------------------------------------------------------------------ 31/03/2023 16:08:35 Client-Info Client Version: 0.11.19 31/03/2023 16:08:35 Client-Info Client OS: Windows 31/03/2023 16:08:35 Client-Info Server Version: 1.5.8 31/03/2023 16:08:35 Middleware::Response Success 31/03/2023 16:08:35 SnapinClient Running snapin boot-uefi-pxe-first 31/03/2023 16:08:35 Middleware::Communication Download: http://148.60.x.x//fog/service/snapins.file.php?mac=B8:85:84:AC:89:FA&taskid=5453 31/03/2023 16:08:36 SnapinClient C:\Program Files (x86)\FOG\tmp\boot-uefi.ps1 31/03/2023 16:08:36 Bus Emmiting message on channel: Notification 31/03/2023 16:08:36 SnapinClient Starting snapin 31/03/2023 16:08:40 SnapinClient Snapin finished 31/03/2023 16:08:40 SnapinClient Return Code: 0 31/03/2023 16:08:40 Bus Emmiting message on channel: Notification 31/03/2023 16:08:40 Middleware::Communication URL: https://fogus/fog/service/snapins.checkin.php?taskid=5453&exitcode=0&mac=B8:85:84:AC:89:FA&newServ

Any idea ?

@george1421 All those binaries are shipped with FOG and installed by default - see the list of ipxe binaries on github.

It’s more or less a question on which binary we make the default when generating the dhcpd.conf - which obviously not everyone is using anyway.

@ITSLUIGICASALE said in How to setup multi-site fog:

I’ve made some work on this, but replication seems to hang many times

Can you be more specific on why you think the replication hangs? Best if you can lost log files to proof what you think is happening.

@Sebastian-Roth thank you for your guidance.