Posts made by JJ Fullmer

@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

@mentaluproar sadly, due to the windows updates previously mentioned, which are actually fully enforced in the 2024-08 updates, a domain admin account is pretty much required to join the domain in an automated fashion. Microsoft gives some guidance on creating policies to allow a least privileged account but I haven’t been able to get that to work with fog. Granted, as long as your aren’t granting access to the fog gui to non privileged users, saving those creds in fog is safe and secured.

@lstassen is the driver the one you expect from the inf when it is installed via fog?
When manually installing are you running an install package?
Is there maybe a device settings tab where you need to tell the driver that the printer has the feature. You can use the fog printer settings file to save and deploy such settings. I haven’t used that feature in quite some time but I helped make it and this type of configuration was why it was added.

@shatchett0 So it is working now on the new install?

A patch version update has been released!

• Fixed an issue with github actions where the release build step wasn’t committing because no user or email address was set, made the github actions bot be the author on those.

• Fixed a typo in the Set-FogSnapins $pkglist param definition, somehow had accidentally made it just string instead of a string array which broke some of my internal scripts so i quickly patched it in case it broke anyone elses

• As a side note, if anyone is curious as to why it jumped from xxxx.6.x to xxxx.9.x that was an accident that I didn’t notice till today… It should have been 2408.7.x. It was probably a typo or I forgot to revert it after the tests of the new build and release system. Since there were already 500+ downloads on xxxx.9.2 I’m not going to go deleting those versions and redoing them as xxxx.7.x. Apologies if anyone caught that and was confused

Release notes: https://github.com/darksidemilk/FogApi/releases/tag/2408.9.3
Full change log:
https://github.com/darksidemilk/FogApi/compare/2408.9.2...2408.9.3
PSGallery: https://www.powershellgallery.com/packages/FogApi/2408.9.3

@shatchett0 I always install with the git method as it makes updates easier, but both should work the same.
I would suggest trying the git method. I’ll have to go test the tar version and see if I get the same result, it’s odd that it’s not showing you what the latest other versions are there, might be an HTTP vs HTTPS thing, might be a firewall issue, I saw something in another forum post where someone’s firewall was blocking the search for latest versions or something like that.

I would also try canceling the task, boot the host to the pxe menu, and use the check compatibility option. Make sure it shows as compatible with FOG and that all the hard drive info shows the partitions you expect.

If you just installed it should have downloaded the latest kernel and init during the install, if you click on that “DefaultMember FOG Version:” box/modal it should expand and show the kernel version.

I also just noticed that your image definition shows Windows 10 (OS ID of 9) but the error message on capture shows osid=50 which is Linux, are you sure you have the right image assigned on the host being captured? (I would also increase the compression level for Zstd to 11, but that’s just me)

@gribbler Are you able to get to the fog pxe boot menu on this host?
If so can you try the Client System Information (Compatability) option?
Mainly want to see option 4 (check fog compatibility) passes (Doing this after what @Tom-Elliott suggested)

Also, if you’re building a custom ipxe.efi file to support the Marvell card, do you happen to have any other cards on this machine that you could try with the default ipxe.efi file?
Do you maybe have the FOG_KERNEL_LOGLEVEL fog setting (in fog configuration->fog settings) up higher than 4? That might explain the extra output you’re seeing

A major version update has been released!
Added various functions and some new features. If you’re using fog 1.6 beta I added some tab complete of your server’s host names dynamically (the api in 1.6 is much faster, so there’s less overhead in making the call to list host names).
Also added a get-fogversion and various other requested features.

One big and often requested thing included is a Set-WinToBootToPxe function that attempts to find the pxe boot entry in a windows hosts bcedit /enum {fwbootmgr} and sets it as the first boot option. I’ve used it with much success in my environment but I need feedback from other environments to make it truly universal.

Another big update is pipeline support. It’s not quite yet as universal as I want, but I added things like get-foghost -hostname somename | add-foghostmac -macaddress 00:00:00:00:00:00

Release notes: https://github.com/darksidemilk/FogApi/releases/tag/2408.9.2
Full change log:
https://github.com/darksidemilk/FogApi/compare/2311.6.4...2408.9.2
PSGallery: https://www.powershellgallery.com/packages/FogApi/2408.9.2

@shatchett0 I’ve only ever used RHEL based linux with fog, currently using Rocky myself. If you’re more comfortable with debian then nothing wrong with that.

Which kernel did you update to? There should be some “experimental” ones from earlier this month that work great.

Also 1.5.10 not 1.5.10.1593 ?
You should update to at least the latest stable version. I can help with that if you need it.

@shatchett0 Got into your fog configuration and check what version of fog you’re on.
Your picture shows the init version, we have newer inits and kernels that might make a difference.
Updating fog and the kernels is fairly easy.

Can you take a screenshot of the image settings you’re trying to capture for? There could be somethign else off there.