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

@Tom-Elliott

Hi, turns out, I had some funk on my network. It was happening on just one machine. I wiped everything, and I mean everything, router, wifi access point, phone, NAS, tablets, PC’s macs, TV’s then rebuilt from scratch, changed all passwords, authenticator everything, new keys… ugh. Rough weekend but all better now. Happy to report the latest FOG dev version is running great, although FOGMulticastManager is leaving zombie processes. I’m about to update to working 1.6 just to check it out.

Fog 1.5.10.1716 Ubuntu Server 24.04.3 LTS

I am experiencing an issue after updating to the latest dev version (see pic). Over the last few releases, FOG has been having problems resizing NVMe drives or producing unusual errors. These errors appear during capture or after deployment, ranging from “Could not adjust bad sector list” to “1 cluster outside the volume.” Usually, a complete drive wipe and Windows reinstall resolves the issue, even though the drive and volume are clean. chkdsk /x/f/r

I previously solved the “1 cluster outside the volume” error by restoring the previous image, shrinking and expanding the Windows partition, and trying again. Unfortunately, that method does not work in this case. I am now stuck at this point:

@Tom-Elliott Hi Tom, Thanks… I updated to 1.5.10.1692 and was able to deploy a 2 day old image to the PC. I updated some things on the PC, mostly with Steam and display settings then went to capture an image from it again and ran into the same problem mention in the OP. Only this time, I was able to take a pic.

I ran chkdsk prior to capturing and it came up clean

UPDATE: So I tried everything for the ntfsresize error … turns out, I had to shrink the partition in windows a bit then expand it. After that, I could capture.

@Tom-Elliott

Some additional info. I believe I was able to successfully capture an image of this PC right after updating to 1.5.10.1688. on Aug 26th. I am restoring a back up FOG from that time to a new VM to see.

UPDATE: So I restored the FOG server back up from a couple of days ago to a new VM and yes, I was able to back up the PC once after updating to 1688.

@Tom-Elliott

Here it is. It is packed

error.log

I updated to 1.5.10.1688 and attempted to capture an image. Win 10 resizable whole disk. It captured the main partition then failed at some point. I couldn’t see the error on the screen. The drive is now too borked to boot into Windows. So I tried to deploy an image I took before the update to the PC but was unable to check in

An idea on how to fix?

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