@Eazis The storagenode can be a master of a different storage group if I recall correctly, but the default storage group should have the master (where the web server is) as the master. There’s a lot of ways to configure it, but for simplicity in testing this out I would suggest 1 storage group with the master fog server as the master node.

What version of FOG and kernel is on the master and the nodes. They should all be the same, latest stable, latest dev-branch, or latest working-1.6-beta would be best as we may have already fixed the issue if it’s not a configuration issue.

@anube Is the bios/uefi firmware up to date on the computer?
Has this device worked before? Or similar MSI devices?
Do you have a pxe capable usb adapter you could try?

@adam1972 I was about to ask for the log.
So it looks like you don’t have the enforce option enabled for renaming the hose and the client thinks that someone is logged in. I’d try enabling enforce, I think it’s actually under the Active Directory settings a little checkbox there, might be under service or client settings on the host.
I’m using 1.6 where it’s moved to under service settings on a host.

@shatchett0 you would cancel the capture task and then boot the host to pxe and you should see a compatibility check in the fog boot menu.
The error also looks like an issue with ext4 thinking it’s a dirty filesystem being captured. If you schedule the capture task with debug checked you can try running the file system check tools interactively. This looks like a problem with this specific host and the image being captured more than a fog server issue.

@adam1972 the double reboot is reminiscent of joining windows computers to the domain and then rebooting a second time to rename in the domain, though fog client has long since done it in one go. Are you setting the ad settings for the Linux hosts? Do the snapins have the reboot box checked in their definition?

@adam1972 if you want to do this in fos right after deploying you could probably use a postdownload script to set the contents of /etc/hostname
You would just need to mount the disk that was just imaged and use sed to edit the file with the $hostname variable. Well there’s a few other steps but I’m on my phone.
I don’t know for sure if that’s still all there is to it as I feel like hostnamectl has gotten more robust in newer Linux releases across all distros, but it’s a good start.

@anube Have you tried ipxe.efi as the boot file?
What version of FOG are you running?

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

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

Just for clarity. Rename in this context also handles moving the file. By “renaming” the file from its old path of /images/dev/$mac to /images/$imagename it’s really moving the file. But since those paths are on different filesystems, it doesn’t work.
The php ftp_put attempts to use an upload of the file from the server to the other path, but that is when it’s actually making the empty file because it gets confused by the paths being on different disks.

@Tom-Elliott @Fog_Newb

I tried this symlink method on my test server and didn’t have success sadly. Seems nfs doesn’t follow symlinks.
My theory on the put function was also wrong.

How big of an issue is this disk size inflation for you? Typically you’re only capturing 1 image at a time, so you need your /images disk to have
(enough space for all your images) + (the size of your biggest image) + (maybe 10% of that for flexibility)
So if your current images take up say 500 GB, and the biggest of them was 100GB (which would be a very big image)
Then provisioning 660 GB should be sufficient if you didn’t want to just double the provisioned space.
If you want to have space to capture them all at the same time, then 1.1 TB would do the trick.
If your images are just really really big, then consider using snapins or other software deployment methods to keep your images to just the base os and a limited number of default apps so that they stay on the smaller side. For examples, my Windows 11 images take up just under 20 GB on the server and around 30 GB on my hosts and then I add the rest per use case within my environment.

You can also play with the different compression levels of the image. I’ve found a zstd compression level of 11 to be a good balance of speed and size.
You could also throw caution to the wind and not care about the speed of deploy and capture and just put the compression to max if you’re more concerned about taking less server disk space.

The only thing I can think of to make this work natively would require database schema changes so you can define separate paths for /images and /images/dev and reworking the install script to make sure the /etc/exports is created correctly. Sadly I don’t think that amount of effort would benefit any other use case and this is an uncommon use case that’s not in our realm of support right now, especially since it’s mostly due to limitations in linux.

The is one other possibility, and that would be a postinit script, but those run before imaging starts not after like postdownload scripts. But there’s other security issues there with how you’d get the ro /images share to be mounted as rw when your task only has permissions to open /images/dev which does have rw. So you’d have to open an ssh or sftp session and send the command to move the folder from /images/dev to /images that way. But securely creating that connection at that point is a different beast. It’s odd that linux/php are having this limitation but that’s where we’re at.

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

In Fog, when this fails, we attempt an ftp_put command aka an upload.
This should work, but there’s a path mismatch at the moment.
During capture the “local” file where it is captured is at /images/{mac} instead of /images/dev/{mac} and the put command is getting the latter because that’s what we already have for the rename command that happens completely remotely.
So I’m testing some stuff to fix this in the dev-branch.

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

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

@Fog_Newb

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

I’m glad you found the security advisory and already changed that back to RO, I panicked a little when I read that.

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

Yes

Then you could at least manually move the image from dev to images to workaround the issue while we work this out.
This feels like a permissions issue, but you already did that step it sounds like.

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

0 bytes

And what does ls -l /images show, I’m curious if it’s a file or a symlink. Either way it’s not what should be happening

What is your php version? php - v

8.3.6

Might be worth upgrading to the latest php version (8.3.11), there was a bug in 8.3.10 (Which I realize you’re not using) that caused an issue with the part of capture where we delete the file that was fixed in 8.3.11, but it was likely fine in 8.3.6.

I’m going to test some of this on my dev fog server and see what happens.

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

That said, the actual moving of files takes place with a remote command of ftp or ssh/sftp not via the nfs share. So it should be working the same.

So in 1.6 does the image stay in the dev folder?
What is the size of the file when it creates a file instead of a folder?
What is your php version? php - v

Another Release! 2408.9.16

• Working towards automated releases, this release was created from an automation triggered by an accepted pull request!
• Added getting gpu inventory to get-foginventory which will work with the next release of Fog and already works in 1.6-beta. Capturing gpu inventory from FOS requires the latest experimental kernel and init as of writing. (EDIT: The required Kernel and Init are now what is downloaded with a Fog install/update by default (latest versions) )
• Fixed some issues with the new Get-WinBcdPxeID, fixed some logic issues and added some helper functions I forgot to include. Tested it in different environments with success.
• Added new Send-FogImage (Deploy fog image) parameters for Fog 1.6-beta and included switches for NoWol, shutdown after deploy, etc. Will later do the same for Receive-FogImage
• Still working out the release note formatting and versioning of automated releases. I have been appending each change where I increment the build version to the release notes, but the automation also append the combined commit of those changes, so some things are duplicated in the full change log.
• The nupkg from the powershell gallery, and the generated nupkg that will be later published to chocolatey (once the current version is approved I can add more versions) are now auto-added to the release assets in github, providing alternate install methods. There’s also a built version of the module in the zip of each release now too.
• I am attempting to unify the overview docs that end up being repeated in the module manifest, chocolatey nuspec, github readme, and about_ help files. I hope to later automate that a bit so it all comes from a single place to edit such.

Currently thinking I’ll switch to a dev branch system where I’ll have a testing version and whenever I pull that in to the master branch a release will be triggered, similar to how we now have Fog setup. That way there’s not a release overload by doing a release for every small feature I add. Hoping that the automatic release notes will include pull requests into dev since the last pull into master. Trying to find ways to adapt to the way github’s automations are designed.

Release notes: https://github.com/darksidemilk/FogApi/releases/tag/2408.9.16
Full change log:
https://github.com/darksidemilk/FogApi/compare/2408.9.3...2408.9.16
PSGallery: https://www.powershellgallery.com/packages/FogApi/2408.9.16
Chocolatey: (Coming soon, Pending Chocolatey Moderator Approval): https://community.chocolatey.org/packages/FogApi/2408.9.3

@kpryor I would just setup a settings.json file and put it in the NetLogon share \\{yourdomain.tld}\NETLOGON
Then add a group policy file preference to update that file after the install.
I think the fog client may also have some msi install arguments available for such configuration but I don’t know off the top of my head.

@Fog_Newb Oh those are random, I thought you were talking about the /images/dev/{mac} that is used when capturing.

So /images and /images/dev are 2 nfs shares on your FOG server. You’ll see this defined in /etc/exports

If you aren’t able to manually move the file on the FOG server from /images/dev to /images then there’s some other weird permissions issue on the server.

When you are capturing an image though, the host boots to FOS, and part of the capture process is mounting the 2 NFS shares from the FOG server, /images and /images/dev. The capture process has partclone writing the captured image files to /images/dev/{mac}/*
Once complete, it moves them over to /images (technically it deletes the old version if any in /images and then moves the new version into its place).
I don’t recall if in the stable/dev branch if we are using sftp yet, so it may be doing ftp (1.6 for sure uses sftp). Point being it does technically remote into the server to do the move operation because the /images nfs share is a read only share.
When you have nfs shares mounted in the same folder that are actually on different disks, I’ve seen weirdness like you’re experiencing is what I’m saying.

So all of that is to say

• Try moving/copying a file from /images/dev to /images on the server directly, confirm that works.
• Try booting into a debug capture session, capture the image (use the command fog and hit enter to step through. Capture any errors.

Technically if you’ve captured the image, you can manually move it on the server to the /images/{imageName} folder and you should be able to deploy as a workaround while we figure this out.

You could also try installing 1.6-beta.

@JJ-Fullmer Maybe if we mounted the shares in fos differently so that they are in different mount paths and not the same on the client/host then this might work, but that’s a bigger change than it sounds like I think.

@Fog_Newb
I think this might be a limitation on the NFS side and the purposely limited permissions of the host when booted into FOS (Fog Operating System) for a task.
I know I once tried to do a separate disk within the /images NFS mount to have drivers I inject on a separate disk. I ran into similar issues, in the end I just made a bigger disks for /images.

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

So anyway it sounds like.

• FOS is mounting both nfs shares correctly.
• 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.

There could be an issue with the nfs exports

If you have another linux machine you could try mounting /images and /images/dev via nfs and see if you can copy in those use cases

@adam1972 So when you’re in a debug mode, or in a fog task in general, you’re booted into FOS (Fog Operating System) which is the same idea as booting from an external disc/drive. The idea being you’re not mounting and booting from your disks that you are capturing/deploying from/to. So after the efsck came back as clean from where FOS could see, it makes sense that it would work as expected right after.
This probably won’t happen every time you capture, if it does then there’s something you’re doing in preparing the image that is causing the dirty bit to be flagged on the disk, there is likely a way around that, I don’t know off the top of my head for Linux what that might be. But we can figure it out if the problem recurs.

@adam1972 that is the debug shell, you can try the efsck command in debug mode then use the command ‘fog’ to step through the capture process