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?

When Logging out of the Web UI I get a “This page isn’t working
10.1.1.100 is currently unable to handle this request.
HTTP ERROR 500”

To duplicate
Click Log Out Of Fog, which directs to this URL http://[ipaddressoffogserver/fog/management/index.php?node=logout

Gives HTTP ERROR 500

Tried on Brave and Firefox

@Tom-Elliott Yes, everything is working as expected. For the longest time, FOG would always show UTC time for when an image was captured or deployed, now it is correctly showing local time and no more zombie processes! Thanks

@Tom-Elliott No worries, thanks for adding that in. I’m going to update in a few to .26 and see what happens. Oh it looks like it is now showing the correct local time on captured images. I’m not sure if this started with .21, .25 or .26. Nothing changed on the system other than updating FOG. This is also excellent!

It’s this http://forums.fogproject.org/post/157404 again.

Thanks all

@Floppyrub said in Wrong target device:

@Tom-Elliott Thanks for your detailed response. I can understand the problem well. On desktops, you can simply disconnect the HDDs if necessary. However, the day before yesterday, I had a laptop with two NVMe drives,

I’ve run into this problem on a PC that had 2 NVME’s, It’s my understanding the reason is, sometimes one NVME initializes first, so /nvme0n is sometimes /nvme1n. If the drives are different sizes, you can specify the size of the target drive / Host Primary Disk (or at least you could). Currently I have 2 NVME’s the same size so I use the serial number of the drive as Host Primary Disk. It works.

Fresh Ubuntu 24.04.3 LTS install running 1.5.10.1721 (started on 1.5.10.1698)

This is what is happening

What to do?

Thank you

UPDATE

I think I may have fixed it. Chat GPT may be a lot of things but it seems to be really good helping with pedestrian level Linux things.

I added this to the Multicast Manager Script under

@error_reporting(0);

// Prevent zombie (defunct) php children
if (function_exists('pcntl_signal')) {
    pcntl_signal(SIGCHLD, SIG_IGN);
}

Then restarted the service. So far it is working. I don’t use Multicast at all so I am not sure if this will impact the way it functions. Does anyone know? @Tom-Elliott

@Tom-Elliott Thanks, going to switch back to 1.6 very soon.

@Tom-Elliott Oh

sshd.txt

@Tom-Elliott psst… https://forums.fogproject.org/topic/18001/problem-storage-node-connection-issues-after-updating-to-fog-1-6

The interface looks nice though

Hi all,

Not sure if this is a bug but…

I recently upgraded my FOG server (running in a VM on Ubuntu 24.04) from 1.5.x to 1.6. The upgrade process went smoothly with no errors, but afterwards I ran into a problem: the Default Storage Node could not connect. In the Web UI, “Test Connection” kept failing with an error about username/password not matching.

Here’s what I’ve done so far to troubleshoot:

Checked the .fogsettings file – confirmed the management username (fogproject) and password were correct.

Verified FTP manually – I was able to ftp localhost as fogproject using the same password, and it worked fine.

Checked the database – logged into MariaDB and confirmed that the nfsGroupMembers table had the correct ngmUser and ngmPass matching .fogsettings.

Looked at the hostname – saw that ngmHostname for DefaultMember was set to the server’s LAN IP (10.1.1.100). I tried updating it to 127.0.0.1 instead, restarted the FOG services (FOGImageReplicator and FOGSnapinReplicator), but the connection still fails.

Restarted services and re-tested multiple times, no change.

Here’s the output of systemctl status | grep FOG showing all services running:

FOGFileDeleter.service
├─1048 php /opt/fog/service/FOGFileDeleter/FOGFileDeleter
└─1115 php /opt/fog/service/FOGFileDeleter/FOGFileDeleter
FOGImageReplicator.service
├─1054 php /opt/fog/service/FOGImageReplicator/FOGImageReplicator
└─1116 php /opt/fog/service/FOGImageReplicator/FOGImageReplicator
FOGImageSize.service
├─1059 php /opt/fog/service/FOGImageSize/FOGImageSize
└─1117 php /opt/fog/service/FOGImageSize/FOGImageSize
FOGMulticastManager.service
└─1062 php /opt/fog/service/FOGMulticastManager/FOGMulticastManager
FOGPingHosts.service
├─1071 php /opt/fog/service/FOGPingHosts/FOGPingHosts
└─1131 php /opt/fog/service/FOGPingHosts/FOGPingHosts
FOGScheduler.service
├─1074 php /opt/fog/service/FOGTaskScheduler/FOGTaskScheduler
└─1133 php /opt/fog/service/FOGTaskScheduler/FOGTaskScheduler
FOGSnapinHash.service
├─1076 php /opt/fog/service/FOGSnapinHash/FOGSnapinHash
└─1135 php /opt/fog/service/FOGSnapinHash/FOGSnapinHash
FOGSnapinReplicator.service
├─1082 php /opt/fog/service/FOGSnapinReplicator/FOGSnapinReplicator
└─1137 php /opt/fog/service/FOGSnapinReplicator/FOGSnapinReplicator

So far, I’ve confirmed:

Credentials are correct (FTP works).

Database values match .fogsettings.

Tried both LAN IP and 127.0.0.1 as hostname.

All FOG services are running.

Still unable to get the storage node to pass the connection test in the Web UI.

Has anyone else run into storage node connection issues after moving to the 1.6 branch? Did something change in how the node authenticates compared to 1.5.x?

Thanks for any advice!