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?

@maxcarpone 1.5.10.2402 is out. It works. I was able to capture from both my PC and laptop successfully. But it has a weird issue with null tasks.

https://forums.fogproject.org/topic/18230/1-5-10-2402-additional-null-tasks-created-but-this-time-manages-to-start-a-transfer

1.5.10.2402 - Additional null tasks created but this time manages to start a capture.

@maxcarpone I had the same problem with 2390 and reverted to an older back up. That version was broke AF

@Tom-Elliott Thanks Tom. 1.5.10.2344 seems to be capturing fine. No additional null tasks were created and the PC had no problem checking in and starting the capture.

I’d swear, not only with this version but the earlier ones that were malfunctioning during check in and creating additional tasks, I had to create the task twice. Like I went through the process of setting up a capture but nothing showed up under tasks then had to do it again.

I can’t seem to duplicate it though. Setting up a 2nd capture for the laptop, I only had to do it once (and no additional null tasks were created).

PC finished the capture no problem and laptop checked in and is capturing now. Looks like 2344 did it!

Thanks again.

@Tom-Elliott Hi Tom, Unfortunately, updating to the latest 1.5.10.2340 gave me the same problem. This time, I tried capturing an image from the PC. I managed to take a screenshot of the strange other Tasks added.

The PC is refusing to check in. LMK if you need any logs and which logs. IIRC, do a debug task. If you can point me to any documentation on where the logs are and how to get the logs you want, that would be great.

I captured from both of my PC’s on 8/19 dev version 2294. Tonight, early am, I updated to 2328, the update appeared to go fine. I set a task to capture from my laptop, (not sure if this is important) before I rebooted the laptop I checked the Tasks list in the web UI from another PC and saw a bunch of other tasks labelled ‘fog’ with parentheses along with the capture task for the laptop. I should have taken a pick. I removed the other tasks leaving only the one for the laptop then rebooted the laptop. Laptop would not check in. Over and over it tried.

I deleted the task for the laptop, rebooted the FOG server and set up a capture for the laptop again. Rebooted the laptop, still the laptop was unable to check in and kept trying over and over.

went back to 2294 all good.

I suspect something is borked in this version. Feel like a POS for not gathering logs but it is late.

@Tom-Elliott Tom, looks like everything has been resolved after going from 2144 to 1.5.10.2218! No errors and I was able to capture no problem. Thanks

@Tom-Elliott Hello Tom, I had posted a pic of the RAM0 error. Since I reverted to a backup of 2144. I no longer get any errors so I can’t take a new pic but here is the original pic with 2191 installed - (see below). I will try 1.5.10.2213 as soon as I can. Perhaps tomorrow evening?

The laptop is booting UEFI. It runs windows 11 with secure boot disabled and TPM requirements disabled during install.

Here is a text translation of the error in case you are unable to view attached photo.

RDSEED32 is broken. Disabling the corresponding CPUID bit.
ACPI BIOS Error (bug): Failure creating named object [_SB.PCI0.GPP5.WLAN._PRR],
AE_ALREADY_EXISTS (20250807/dswload2-326)
ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20250807/psobject-220
)
pcieport 0000:01:00.0: Unable to change power state from D3cold to D0, device in
accessible
pcieport 0000:02:00.0: Unable to change power state from D3cold to D0, device in
accessible
Kernel panic - not syncing: VFS: Unable to mount root fs on “/dev/ram0” or unknown-block(1,0)
Kernel Offset: disabled
—[ end Kernel panic - not syncing: VFS: Unable to mount root fs on “/dev/ram0” or unknown-block(1,
0) ]—

“2144 good, 2191 bad”

Yes, that is the kind of in-depth analysis I am known for.

@Tom-Elliott I’m sorry. I restored a previous version of the FOG server and no longer have any error logs from when all this happened. I can go to 1.6… IIRC there is a change that needs to be made to SSHD conf or something. The last time I went to 1.6 FOG was unable to see the default storage node.

Everything working fine until this latest FOG update. Using a Strix Point laptop with a USB Ethernet adaptor. Also trying to install different kernels through the web UI no longer works. HTTP ERROR 500

I tried installing master branch. Failed, couldn’t even boot to memtest. I restored the FOG VM from a back up made a few days ago. 1.5.10.2144 - everything is working as normal now. Afraid to update

Just thinking, sometime between the 1.5.10.2144 backup, there were tons of dev updates, and one time when I did a git pull on FOG, it deleted a bunch of things. But since the gui worked, I assumed it was okay