SOLVED

I was on 18.04 and ran “sudo do-release-upgrade -d”, It finished, I rebooted and was able to access the FOG web interface and deploy an image. I am running the latest stable version: 1.5.8

UPDATE: I had some issues when I upgraded to 20.04 on a different FOG box. It has been resolved.

Thanks

@sebastian-roth The error during the FOG install on 21.10 is related to installing php 8.0 mysql

If I try to manually install php8.0-mysql it appears to be installed already

The GUI works fine and capturing an image goes smoothly until the end where the database needs to be updated

Wow, so I ran the FOG installer again, this time there wasn’t an error when it came to the mysql install.

Going to try capturing an image now.

Hmm. It still fails to update the database.

@Sebastian-Roth

Yes.

I just want to add real quick, the DC 7800’s can boot to the menu with any kernel and without and kernel parameters. They fail when deploying.

I installed the leaked dev version 21996/21996.1 on bare metal and in a VM. Secure Boot didn’t have to be enabled . UEFI and TPM (which requires CSM to be disabled) had to be. Secure Boot - the option only had to be present.

After more testing. I found I could install it in a VM as Legacy. I guess MS laxed on the VM requirements?

I also found on metal, I could disable TPM and enable CSM which should make secure boot completely unavailable. Then I deploy a sysprep-ed Win 11OOBE UEFI image on it without any problems.

I will try pure legacy on metal next…

This was with that leaked dev build so who knows if it was modified or what not and how close it is to the actual dev build release or the final release.

3.13 that comes on the latest dev-branch as of today has issues with APFS on my laptop.

3.20 x64 does not

@Sebastian-Roth

Hell yeah dude, that cleared it right up.

@Sebastian-Roth

Not sure if this has been resolved or if this helps -

I’ve created a Win 10 UEFI VM using the 2004 ISO. VMware Workstation 15 Pro 15.5.6 build-16341506. All the settings were default except I went up tp 8GB of RAM. I installed it, ran all the updates, activated it while waiting for updates, rebooted twice then captured the image with FOG dev-branch version: 1.5.9-RC2.11 running on Ubuntu 20.04 LTS

It deployed fine to a similar VM.

@sebastian-roth Thanks. I just updated to the latest. So far it is capturing an APFS drive on a hackintosh no problem.

@Sebastian-Roth

So yes, this is a perfect solution since Primary host disk can now be set by size. I have one image for the OS disk, and one for the “D” drive. I just switch the Primary Host disk setting depending on which image I want to capture or deploy.

@george1421 I boot from a FOS usb stick that pxe boots to the FOG server. So I am thinking put the T2 Kernel on the server and specify that kernel under the “host kernel” setting for the macs, then on the the FOS stick put the t2 kernel as well?

@Tom-Elliott Fog now tells me the latest dev version and the one I have is 1.5.10.1671

Was 1.5.10.1771 all a bad dream or were we both mistakenly calling 1.5.10.1671 1.5.10.1771?

@Tom-Elliott Thanks. I grabbed a full fresh release but haven’t had a chance to reinstall 1.5.10.1771 over itself to confirm the included inits work. But if they are the same inits you posted earlier… it definitely should

@Tom-Elliott Awesome sounds good. Another one can be marked as Solved

@Tom-Elliott No, but I just did now and it is working! Thank you. So for now, whenever I update FOG, I should copy over that init until it is worked into the dev or release version?

@Tom-Elliott Thanks.
I grabbed the new init.xz and copied it to /var/www/fog/service/ipxe/ and I was still able to capture the an image from the PC with FOG 1.5.10.1667. I updated FOG to the latest 1.5.10.1771 and tried to capture from the PC again and it failed with same error.

@Tom-Elliott sounds good!

@Tom-Elliott

Yes, I will test these as soon as they are available and have access to the PC, around 2pm EST. Just to confirm, the steps to test would be - update to 1.5.10.1771, then drop the everything into /var/www/html/fog/service/ipxe/ and try to capture again?

Thanks

@Tom-Elliott Should add… I have 2 NVMe drives that are the same size. And since they initialize randomly at each boot, I can’t specify /dev/nvmeXXX
https://forums.fogproject.org/topic/14822/nvme-madness?_=1753960837885

At some point, a few years ago, someone said you could use the drive serial number if both NVMe drives are the same size, and it’s been working for a long time now.

@Tom-Elliott

Hello Tom,

Yes, I am using the disk serial number (21297930000130911023) in the Host Primary Disk field. It’s been working fine going on a few years now.

FOG 1.5.10.1667 to 1.5.10.1771

Running on Ubuntu 24.04.2 LTS

Last night, I captured an image from my PC. FOG was version 1.5.10.1667 everything went fine. Today I updated to FOG 1.5.10.1771 then went to test capturing an image from that same PC, no changes were made hardware wise etc.
This happened. No valid drives found

NOTE: I use the drive serial number for Host Primary Disk because I have 2 NVME drives which are the same size. <— Could this be the problem?

I bypassed PXE boot and went into Windows fine.

I restored the FOG server (It’s running in a VM) from a backup prior back to 14 hours earlier version, when it was running 1.5.10.1667. And it captured fine. What is going on!?