@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.

@Flyer said in WOL Not Working After Imaging:

I guess they only way to know is to test.

Exactly. 🙂

@Sebastian-Roth
Thank you Sebastian, I will give that a try. Thanks again for the excellent support! You can close this ticket.

With the bad RAM removed the system imaged just fine with the same image. Thanks again.

@DCSOTech OK make sure I understand, you have a 6TB drive that already has FOG images on it and you want to preserve your image files?

If the drive is already connected to your fog server (but not necessarily ubuntu) key in this command and put the output here.

lsblk

This command will show block devices on the computer (think hard drives). From that output we can give you the next steps.

Also one question to avoid many turns on questions. Is your current fog server a new fog server without any captured images, where you want to bring in the new 6TB drive before you start capturing images? (its important to know the approach we will take to connect the drive if we need to save what is currently on the fog server).

Hi, thanks for the reply and information. I was able to solve my problem, by using the fog-api in the postdownloadskript. Now i am able to read the hosts group-name and create automatic dessiscions for manipulating the unattend.xml in windows based on that.

Best,
Floppyrub

screenshoot2.png

screenshoot3.png

screenshoot1.png