Posts made by JJ Fullmer

@ramone As far as I am aware, no one ever volunteered to take up the docker image maintenance. It’s essentially dead.
I think it’s possible in theory, you would just need volumes for the fog directories that need to be static between updates like the database and images, though there would surely be other fun issues with ports to work out. I personally see the desire for it if you’re in an environment where you already have lots of containers as a standard in your infrastructure, but I like having it just on its own server.
Is it not an option to start with a docker image that doesn’t already have a database on the default port? Or are you saying the docker host already has a database on said port?
I’m also sure we could figure out using an external database as storagenodes already connect to an external database. I would think that using docker for adding storage nodes might make some sense as you could put them all on one server and use volumes to mount disks from different sources.
However, the more virtualization and containerization you add, the more complication arises. Already once just on a virtual server you may not be able to use multi-cast imaging unless you’re able to add igmp snooping in your virtual networking. I don’t know if containers have that same limitation or other limitations that could be introduced.

This isn’t really a great answer I realize, and I apologize for that, but there’s a lot to consider with changing infrastructure.

Anyway, something you might try is to create a /opt/fog/.fogsettings file before installing and put in these settings

snmysqlpass='password'
snmysqlhost='remoteHost'
snmysqluser='fogmaster'
mysqldbname='fog'

Then try the installer, no idea if it would work, but something to try as far as using an external database.

@gaptoothgonni So while this can be done, FOG is designed to capture an image from where windows is already installed and sysprep’d, not to boot to a wim. Of course it can be done, but I just wanted to make sure that’s clarified.

All that said, doing it that way may or may not get past your problem, because it may just be a client pc bios setting.
If you manually boot to that iso on a usb on that pc, does it see the disks?
That message generally means it’s missing the storage driver.
Does the host you’re trying to deploy to have VMD/RAID enabled in the bios settings?
It is possible, and not even that hard if you’re already customizing the iso, to add the storage driver to the wim. I’ve never used NTLite, but in powershell you can mount the wim of the image with Mount-WindowsImage and use Add-WindowsDriver to add the inf you need to that image. You probably need to mount the boot.wim and setup.wim images and add it there too as you’re booting to the boot.wim and using winpe. This page might also be helpful https://learn.microsoft.com/en-us/windows/deployment/update/media-dynamic-update#update-windows-installation-media

I would also say, if you’re going this route, to consider making a autounattend.xml if NTLite doesn’t do that, as it can automate the install of windows and then have it kick things off into provisioning. We customize an iso like this and use it to create and capture our base image in FOG.

I got a little off topic there, TL;DR
Make sure the disks are seen if you boot to the iso manually, if they are not, then adjust the bios/uefi settings to use AHCI mode for disks as it works universally. If the disks are seen when manually booting, then something else is causing it not to see the local hardware.

@chunter2 It does look like you’re on an older version of fog. Updating to the latest stable, dev-branch, or my favorite working-1.6 version may help.

But also, are you saying that you joined the domain, then unjoined and then captured an image of that? Generally you don’t want to join the domain where you’re capturing, it’s much cleaner if it’s never joined the domain.
Or are you saying you’re trying to re-join the domain on a normal host? This could be an issue on the host’s settings in fog, could that have been changed on accident? Maybe autofill from a password manager changed the domain and or domain join password?

Another Release(s)! 2506.9.22
https://github.com/darksidemilk/FogApi/releases/tag/2506.9.22

2506.9.19-22 are a slew of releases where I kept finding issues in broader tests right after I released each version. So apologies for the over-releasing there.

• Fixed send-fogimage to work with more use cases and utilize more parameters available to scheduled tasks like bypassbitlocker. Also simplified the parameter sets to avoid errors when using the command with different parameter sets.
• Also added links to PSGallery and chocolatey in each github release going forward.

Full Release Note History: https://fogapi.readthedocs.io/en/latest/ReleaseNotes/
Powershell Gallery Listing for this version: https://www.powershellgallery.com/packages/FogApi/2506.9.22
Chocolatey Package Listing for this version (may take 1-60 days from release to be approved by chocolatey moderators): https://community.chocolatey.org/packages/FogApi/2506.9.22

@Ced58 I use this model. It’s best to get either the official Lenovo usb c ethernet adapter or the proprietary Lenovo adapter for the special ethernet port on these. Also in the bios there’s a Mac pass through option that you want to set to internal or second Mac address. With the latest version of fog and kernel it should see that internal mac even if you share an adapter for imaging multiple of that device.

@joshua_mchugh George’s mention of using a post install script to do it is more advanced but very worth the effort. Having it domain joined via sysprep specialize simplifies things in the long run.
That being said, you’re probably misunderstooding groups, because they’re a little confusing. Groups in Fog do not dynamically update the OU of the host members, but it can be used to set the OU in bulk on members. There is a plugin to change the behavior of groups if you want, but I’d try it the normal way first.
But if you set the OU on the host, then when it joins the domain via the fog client, it will be in that OU. It will not move a host to a different OU, unless you do something like manually leave the domain and change the computer name and then the fog service will rename the computer back to what it is in fog and then join the domain in the set OU.

I personally use a post install script now that grabs the OU from to host and Injects that into my unattend file. I believe I’ve posted some examples in the past. If I remember tomorrow when I’m at a computer and not a phone, I’ll link them.

@John-L-Clark what version of fog are you running?
I would also suggest enabling the Mac address pass through.
You could also try an older ipxe file

@argylega have you restarted the Mariadb and apache services, or the whole server?
I also assume you mean you can’t login to the website. Is there anything in the apache error log?

@NoIPName Can you share your import csv perhaps? It seems to think it’s missing a value based on the error message. I will gladly test the same csv on my dev server and see if I get the same result so we can debug this more hands on.

@altitudehack The supported workaround would be to use 1 universal script that can just take the arguments of a command.
i.e. a simple powershell script like this

[CmdletBinding()]
param (
    [string]$exe,
    [string]$argz
)

start-process -filepath "$exe" -arguments "$argz"

There might be more needed there, but that’s the general idea.
Then you just use that same script each time you need it. Then lets say you call it runCmd.ps1

you would make a snapin with the powershell template and that runCmd.ps1 (once uploaded once you can create snapins with the existing file)
In the snapin arguments field you would put something like -exe "C:\program files\some program\uninstall.exe" -argz "/S"

@danieln
Check out the FogApi powershell module, links in my signature.
I even have functions for setting snapins already

https://fogapi.readthedocs.io/en/latest/commands/Set-FogSnapins
https://github.com/darksidemilk/FogApi/blob/master/FogApi/Public/Set-FogSnapins.ps1

and for starting snapins

https://github.com/darksidemilk/FogApi/blob/master/FogApi/Public/Start-FogSnapins.ps1
https://fogapi.readthedocs.io/en/latest/commands/Start-FogSnapins.ps1

https://github.com/darksidemilk/FogApi/blob/master/FogApi/Public/Start-FogSnapin.ps1
https://fogapi.readthedocs.io/en/latest/commands/Start-FogSnapin.ps1

@NoIPName Can you get to https://192.168.1.1/fog in a web browser without any cert is bad prompts?

Because pxe wants to use the ip address in the url you have to have the ip address san in the certificate that your fog web server is using.
That cert for the web server needs to be from the custom ca.
That public cert can also affect client communication if you change it in the default path from fog install.

@bwilli78 I would try ipxe.efi instead of snponly.efi for testing the pxe boot file route. .kpxe and .kkpxe boot files are for legacy systems that don’t support UEFI. However it sounds like you’re getting to the fog pxe boot menu so that’s an unlikely culprit.

Where in the process are you getting the kernel panic?
Are you queueing the imaging before hand or are you queuing it in the fog boot menu?

The general process is

1. Boot host to pxe
2. Host contacts pxe server defined in dhcp and requests pxe bootfile listed in dhcp
3. Host boots to the pxe file which takes it to the fog pxe boot menu
   a. If the host was queued for a task it downloads and boots the FOS kernel instead of the pxe boot menu
   b. Or, user selects a task and then host boots to FOS kernel to perform the action
4. Kernel loads into FOS and performs the task.

Where in this general overview are you seeing this error?

@lperoma What do you get running mariadb -V

@iljared98 I don’t suppose you’d be willing to share more on this config? What specific rights you gave the service account, did you have to do this whole thing https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1 related to this whole thing https://support.microsoft.com/en-us/topic/kb5020276-netjoin-domain-join-hardening-changes-2b65a0f3-1f4c-42ef-ac0f-1caaf421baf8 ?

I’ve previously attempted to create a standard user with such permissions, but I hadn’t tried a service account, that’s a grand idea. I would love to document the creation of a least privilege service account for fog domain operations.

@Quintin-Giesbrecht It’s been a while since I’ve had to mess with it, if memory serves it may show in the output of the imaging itself. You might need to do a deploy in debug mode on a fast/normal speed machine and then a slow one and compare what you see.

You may also find some logs in the log viewer of fog within the fog configuration page. Where the logs are on the server depend on your fog version and your OS version.

Like for me on Rocky 9 with Fog 1.6 and using apache with php 8 the log with the most information is /var/log/php-fpm/www-error.log but I don’t believe kernel level stuff will output there.

@Laurent https://docs.fogproject.org/en/latest/installation/server/install-fog-server/#choosing-a-fog-version

Essentially, instead of checking out the stable branch and doing a git pull and running the installer, you check-out the working-1.6 branch, do a git pull and run the installer.

It’s still in “beta” but I believe we’re very close to releasing it as the new stable version.

It’s a whole new ui it’s pretty great. Lots of feature and security enhancement in the backend, faster search results in a universal search tool, cool stuff like that.

@Quintin-Giesbrecht I think there’s potential for a solution for it but it’s tricky to nail down. I imagine you’ve also tested machines that go faster on the same ethernet cable and port? It’s very odd that it would capture fast but not deploy fast. What level of compression are you using on the image? iirc when uploading the image, compression happens on the fog server, when deploying the image decompression happens on the client. So if your compression is too high, it could cause this behavior but it would be more wide spread.

You could play with making a custom kernel (see https://docs.fogproject.org/en/latest/compile-fos-kernel) adding different driver options that might relate, but since the network is already being recognized I’m not sure that would make a difference. It could also be a storage level issue rather than network which could also be something in the kernel.

You can also adjust the kernel log level settings to be higher and you’ll get more output that might point to a different problem.

Also be sure your bios is up to date and navigate through the bios settings for anything that seems like it could relate.

There’s also playing with the different pxe boot files (i.e. ipxe.efi vs snponly.efi) this shouldn’t really make a difference once you’re in part clone and imaging, but I figure it’s worth testing all parts of the process when you’re not sure where the problem lies.

I would also check the fog server dashboard, specifically the bandwidth reports and see if there are lots of dropped packets, perhaps there’s a different network configuration needed for this model?

@Laurent said in Problem with FOG Service …:

I use an encrypted password because I don’t want other fog users to see my password in plain text

I would recommend using a separate domain admin account rather than any 1 user’s domain account. Partly because of the issue you describe (though that’s not something that can be seen in the web gui) but also so that it’s a password that won’t expire with a user leaving and it’s a password that can be rotated without affecting other services.

Just my 2 cents.

@sideone Are you getting different IP addresses in the snapin download url and the communication url? i.e. is the communication URL going to your master and the download going to a storage node? Maybe a storage node has something goofy in its storage node config?

The communication url is derived from the c:\program files (X86)\Fog\settings.json file where it uses the Https flag, server name, and webroot values to construct that base url i.e. http://10.xx.xx.xx/fog
I’m not sure if the download url is combo of the settings.json file with info from the server or if it’s just from the server or what. But your download url is missing the http/https and is also has an extra slash.

P.S. you don’t really need to hide the ip of the fog server. It’s an internal subnet only ip address, it doesn’t expose anything to say what ip you’re using. Do whatever makes you feel safe, just saying is all.