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

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

Fog 1.5.10.1667 Running on Ubuntu Server 24.04.2 LTS

The PC’s the images were captured from were set to use Windows time.
The FOG server, tzlocal is set correctly to NY Time and so is fog.

The 3 images from the 2 PC’s were captured a little past 4:AM July 16th. But the dashboard shows they were captured on the 15th.

The image section under FOG shows the correct date and UTC time the images were captured not local but that isn’t a big deal and I can’t figure out how to change it to show local time.

I set both Windows PC’s to use UTC time, then captured an image again.

It is 6:19pm July 16th The FOG server and both Windows PC’s know this

But the FOG Dashboard see’s all 4 images being captured on July 15th

The FOG Images section shows it was captured today but doesn’t show local time even though FOG is set to NY timezone

@Small0145 No, it’s not.

FOG 1.5.10.1667

Running on Ubuntu 24.04.2 LTS

I updated to the latest FOG dev version a couple of days ago and tried capturing an image from my PC after installing July 8, 2025—KB5062554 (OS Builds 19044.6093 and 19045.6093) Win 10 LTSC Enterprise

I got
This error

I ran a chkdsk /x/r/f on reboot, drive came up clean

https://pastebin.com/KHc6vd59

Error persists even after running chkdsk /x/r/f, then trying to capture.

I rebooted the FOG server, then installed the previous version FOG 1.5.10.1660 - Same problem

Crystal Mark Info shows SMART is good, drive is fine. I restored the last captured image to the PC, ran the Windows Update and tried to capture, same error.

@Tom-Elliott All good with 1.5.10.1629

Thanks

After updating from 1.5.10.1622 to 1.5.10.1625, I went to capture and image and got error message in the subject. Then I saw After updating from 1.5.10.1628 was available so I updated to that,

What do?

@JJ-Fullmer @Tom-Elliott

I’ve found a work around. I now have /images on USB HDD passed through the to VM. When I run a standard back up of the VM via the VM software (Virtualization Station), it only back-ups the OS VM drive.

For the /images drive - I use a sync program to back-up the files, not the disk .

I thought I’d posted about this before but it doesn’t show up in my post history. After capturing an image, Image Size ON SERVER shows as 0 or sometimes 1GB/MB. All the partitions and other information were captured successfully in /images/[imagename] and are the correct size. Once the FOG server is rebooted, Image Size ON SERVER displays correctly.

Thank you

@JJ-Fullmer said in FOG has issues if the temp image location is on another drive. FOG 1.5.10.1612 Ubuntu Server24.04.1 LTS:

How big of an issue is this disk size inflation for you?

It’s not a big deal. I’ve since stopped capturing non-OS drives and now use file sync / mirror program to back those up. I actually like that better than huge image captures once a week. Currently, FOG is just capturing 2 relatively small OS drive images.

All this is running on a QNAP box someone gave me and QNAP’s Virtualization Station software is lacking features to cleanup/shrink or compact virtual machine disks.

This all started out as a Feature Request

https://forums.fogproject.org/topic/17651/local-time-and-alternate-temp-directory-for-capture-option

It’s odd that linux/php are having this limitation but that’s where we’re at.

Is this something the devs would change if it was brought to their attention?

Thanks

@Tom-Elliott

Ok I think I have it set up how you asked

New mount points

Symlinks

Gonna try to capture will report back

Same thing.

@JJ-Fullmer said in FOG has issues if the temp image location is on another drive. FOG 1.5.10.1612 Ubuntu Server24.04.1 LTS:

@Fog_Newb I think I found the problem.

Normally the ftp_rename command successfully handles moving the captured image from /images/dev to /images but for some reason that command ( a built in php/ftp thing) doesn’t like it when the directories are mounted on separate disks. Not sure why, doesn’t make a ton of sense, but that’s the issue.

That makes sense to me especially if that command is only able to rename.

Basically I think you may have found a bug in a failsafe method for uploading a captured image.

Cool cool?

@Tom-Elliott said in FOG has issues if the temp image location is on another drive. FOG 1.5.10.1612 Ubuntu Server24.04.1 LTS:

I will definitely try this. Just to make sure I understand how you want these new directories mounted…

sudo mkdir /images1
sudo mkdir /imagesdev1

Then adjust fstab so ‘/images1’ is a mount point for one drive (where /images was mounted), and ‘/imagesdev1’ is a mount point for the other drive (where /images/dev was mounted. Mount them, once mounted then I do…

After mounting these, new mount points, everything that was in /images and /images/dev is now in /images1 and /imagesdev1

sudo rm -rf  /images
sudo rm -rf  /images/dev
sudo ln -s /images1 /images
sudo ln -s /imagesdev1 /images/dev

Then capture an image and see what happens

@JJ-Fullmer said in FOG has issues if the temp image location is on another drive. FOG 1.5.10.1612 Ubuntu Server24.04.1 LTS:

@Fog_Newb I am able to recreate the problem in the latest stable version (1.5.10.1615). Working it out. it looks like the image does stay in dev on my end.
I’ll debug this when I can this week.

Awesome. Thanks.

Then you could at least manually move the image from dev to images to workaround the issue while we work this out.

I have another FOG server set up where /images and /images/dev are on the same drive so I can continue using that until things get sorted.

@JJ-Fullmer said in FOG has issues if the temp image location is on another drive. FOG 1.5.10.1612 Ubuntu Server24.04.1 LTS:

@Fog_Newb Fog is creating NFS shares from your 2 disks at those mount points. If they were not shared, imaging would not work. On the server the paths are mounted to different disks. And then each of those paths are shared, you can see this if you run cat /etc/exports where the shares are defined.

Oh I see

Why is /images ro? Shouldn’t it be rw? How do I change that? I’m going to edit the /etc/exports file and change /images to rw and test

So I edited it - from ro to rw saved and rebooted but same results.

I guess ro is the way /images is supposed to be as far as /etc/exports

https://github.com/FOGProject/fogproject/security/advisories/GHSA-3xjr-xf9v-hwjh

So in 1.6 does the image stay in the dev folder?

Yes

What is the size of the file when it creates a file instead of a folder?

0 bytes

What is your php version? php - v

8.3.6

@JJ-Fullmer said in FOG has issues if the temp image location is on another drive. FOG 1.5.10.1612 Ubuntu Server24.04.1 LTS:

So /images and /images/dev are 2 nfs shares on your FOG server.

They are both local drives on the FOG server formatted GUID ext4. Everything is on that machine. There aren’t any network drives or shares.

Try moving/copying a file from /images/dev to /images on the server directly, confirm that works.

Yes, moving and copying from /images/dev to /images and visa versa works fine.

Try booting into a debug capture session, capture the image (use the command fog and hit enter to step through. Capture any errors.

There are no errors during the debug capture process.

Oddly enough, FOG/FOS will attempt to create the directory on /images, but it creates a file instead.

So, If I try to capture a new image named “BigBox”, after the capture there will be a file, not a directory, in /images named “BigBox”, - but that is it. Everything else stays in /images/dev/{mac}/*

Updated - I’ve tried FOG 1.5.10.1615 (coming from FOG 1.5.10.1612) and 1.6.0-beta.2130. Same results and no errors during debug-capture.

*1.6.0-beta.2130 does not create a file named after the image in /images

P.S. I now see what you mean by “the random numbers” being MAC addresses (the temp directories for the images). I thought you were talking about the other ‘random numbers’

@JJ-Fullmer said in FOG has issues if the temp image location is on another drive. FOG 1.5.10.1612 Ubuntu Server24.04.1 LTS:

@Fog_Newb

• FOS is writing to the /images/dev share
• FOS can’t move the files from one share to another when the shares are on different disks.

exactly

FOS is mounting both nfs shares correctly.

In my case, there’s no NFS shares involved, unless I’m misunderstanding.

/images and /images/dev are ‘mount points’ of the 2nd and 3rd local hard-drives on the VM. Maybe I’ve been using the term ‘mount points’ incorrectly

Also, just an FYI, it’s not random numbers, it’s the mac address of the host being captured.

When I mentioned random numbers I was talking about the numbers listed during the ubuntu install for the disk drive device numbers.

They weren’t the UUID’s of the drives or partitions and looked too long to be MAC addresses