https://www.memtest.org/

https://github.com/ipxe/ipxe/releases/tag/v2.0.0

I’ve installed Linux Server with a static IP and successfully configured FOG. Everything seems to be running fine—I’ve already captured two Windows VM images without any issues.

However, I’m having trouble deploying these images to physical hardware. Here is what I’ve done so far:

Disabled Secure Boot.

Set the boot priority to Network Boot (IPv4).

When I start the physical machine, it attempts to boot from the network but quickly shows a “Failed” error and proceeds to boot into Windows normally. It happens too fast to read the full error code, and I can’t reach the FOG menu to start the deployment.

What could be causing this PXE boot failure on physical machines while VMs work fine? Any tips on how to fix this?

I’m running v1.5.10.1826

This is what I had to do, was in the same boat.

Go to /opt/fog/.fogsettings

Remove the sysv-rc-conf entry from the packages line from there. (Reference: https://github.com/FOGProject/fogproject/issues/797)

Lower down in the same file, set “php_ver=‘8.2’” to “php_ver=‘8.4’”

Exit and save.

Then I had to remove symlinks in Apache that were using the old php modules:

sudo unlink /etc/apache2/mods-enabled/php8.2.conf
sudo unlink /etc/apache2/mods-enabled/php8.2.load

Then add the new links:

sudo ln -s /etc/apache2/mods-available/php8.4.conf /etc/apache2/mods-enabled/php8.4.conf
sudo ln -s /etc/apache2/mods-available/php8.4.load /etc/apache2/mods-enabled/php8.4.load

As @Tom-Elliott stated, this is not an issue with FOG itself, instead FOG relies on tools like ntfs-3g and partclone to handle all the NTFS filesystem changes. Hopefully this updated version fixes your issue.
I will update the thread once the experimental release is available.

J’essaye de passer de la version 1.5.9 RC2 en 1.5.10 mais j’ai cette erreur sur la partie “Updated/Installed”

 * Compiling iPXE binaries trusting your SSL certificate.......Failed!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!! The installer was not able to run all the way to the end as   !!
!! something has caused it to fail. The following few lines are  !!
!! from the error log file which might help us figure out what's !!
!! wrong. Please add this information when reporting an error.   !!
!! As well you might want to take a look at the full error log   !!
!! in /root/fogproject/bin/fogproject-stable/bin/error_logs/fog_error_1.5.10.1826.log !!

Fichier de LOG

/usr/bin/lsb_release
/usr/bin/systemctl
systemd
/usr/sbin/iptables

Pouvez-vous me guider pour résoudre ce problème ?

En vous remerciant.
Bonne journée.

This is fixed, too, and can be marked as solved. The reason was stale WOL power action. I deleted those manually from the DB, and the CPU went back to normal.

I’m not sure about the SSH and replication issues, but I deleted my physical storage node, and I’m not seeing those anymore.

I have pushed a few mroe adjustments in an attempt find and fix more bugs (thanks AI review and whatnot)

Please pull and let me know if there’s any other issues.

Secure boot is meant to be… well, secure.

There are people attempting to get there, but I can say, right now, FOG just isn’t there right now.

On the forums you can see this at:
https://forums.fogproject.org/topic/17949/fog-secure-boot-with-shim

Which might help lead you in the direction as well hopefully.

We are preparing a lab with 44 MacBooks (Apple M4, 16 GB RAM).

Currently, we have not implemented any imaging solution yet. At the moment, we only use our Samba Active Directory domain for user authentication (LDAP/Kerberos) on the Macs.

All machines have the exact same hardware configuration, and we need a way to create a standardized macOS image and replicate it across all devices. This deployment process is performed once every semester, so we are looking for a reliable and repeatable solution.

We are evaluating the FOG Project as a possible solution, but we are unsure whether it supports cloning and deploying macOS images on Apple Silicon devices (M4).

We would like to ask:

Is FOG suitable for capturing and deploying macOS images on Apple Silicon Macs?
How does the cloning process for macOS work in this scenario?
If FOG is not recommended, what tools or best practices would you suggest for mass macOS deployment and domain integration with Samba AD?

Thank you for your guidance.

@KMEH Well, it must be another image I couldn’t attach.

Which image are you referring to here? bzImage? If so bzImage is the filename of the kernel.

I’ve honestly dedicated many hours to this without success. I’ve seen another project called foguefi (https://github.com/abotzung/foguefi), compatible with Secure Boot directly, without using MOK, and it works. It’s just that when you select options like quickreg or deploy an image, it takes forever. But the point is, it works with recursive boot enabled. It shouldn’t be that complicated.

Yeah, I am aware of foguefi (I actually reference it in the original post), but I think you are slgithly mistaken, it actually is also using MOK. It chains grub via shim (which is similar to what we’re doing here, chaining iPXE via shim) and then re-implements the iPXE menus into grub. This works great, but requires a lot of maintenance effort if anything changes upstream in FOG.

As you can see that project is currently archived, but FOG is also reasonably stable, so I’m not sure how long it will take for a breaking change to stop it from working. Part of the reason I devised this method is that (although hackier to implement on a user level), it doesn’t rely on any functionality that isn’t already present in standard FOG server itself for the most part and it could reasonably be implemented by the FOG developers should the wish to add it.

Anyway, do you have a list of commands to configure it? Maybe I or the AI ​​is missing something.

Sorry I’m a little lost here, commands to configure what? foguefi? If so I’m not sure, I haven’t used it myself so you’d have to ask the developer. If it’s commands to configure my method, the guide above should have everything you need.

Not because it’s not a QOL improvement (it is) but because what you see in 1.5.x.x is NOT what is the end goal.

If you want to see what the UX is moving toward install the version of FOG on working-1.6.

You’ll understand (I hope), then, why I’m saying this.

Interesting note that you’ve seen it cause boot issues on certain Linux VMs. I have not experienced that behavior yet but will keep an eye out for it.

If it’s just a “saying” I can understand that but from a technical standpoint what this means is completely different and would need logs. If all you mean is the machine in quesiton is hanging, that’s a different issue altogether. I highly doubt the whole FOG Server is crashing.

I’m currently trying to upgrade our server from running on HDDs to SSDs. We have about 50 computers already running FOG, which I’d say has worked good. I have installed the new SSDs in the server, reinstalled fog, done the standard Debian setup and imported the hosts. I had an issue were I were not even able to capture an image because in became invalid, and didn’t display any date. I fixed this by giving rights to wright and read in the folder.

The issue is now that I’m neither able to deploy the image nor won’t the computers start if it’s set in bios to start from network (fog). When they start via fog I get to the meny, but then afterwards a black screen with a blue strip at the top saying rEFInd - Initializing, and nothing more. I’m guessing there is a file or something I have missed to move from the “old server” to the new one. (I do still have access to the old files If swap the SSDs for the HDDs). We have tried fully copying the FOG from the old to the new, but there were some issues because of different drive sizes and arrangements.

Could someone please tell me what I have missed or what could be the issue now. Thank you!
I’m sorry if I missed to specify something important, feel free to ask for any needed information.

Thank you so much in advance!

Kind regards,
William Moliis