@meie1kyl on your fog server, please login, either as root or a user who can sudo to root:

Become root user:

Then run these commands for consistency (you can change location but will need to remember to make that adjustment every time for updates.)

cd /opt
git clone https://github.com/fogproject/fogproject.git latest_fogproject

# These commands after for updates
cd /opt/latest_fogproject
git checkout dev-branch
git pull
cd bin
./installfog.sh -y

Of course make sure you have a backup but this should get you where you need to be.

@meie1kyl What version of fog are you running?

When you login at the bottom right corner you should see the actually installed version of FOG.

What version is that?

I suspect you’re using a version that is explicitely tied to 20230305.

@DBCountMan It’s most likely somethign that might be implemented in a future release, but isn’t really on the focal point.

Why?

Basically when imaging log was initially created it was entirely built to be tied to registered hosts, and most likely (at that time) the only way to DO anything imaging wise was purely by registered hosts.

What might make mroe sense is a separate imaging log that simply tracks ALL imaging tasks but is linked to “images” as images must always be registered. Just my thoughts.

This is just me spitballing, it is in no way being worked on currently.

Basically I want to create a new table that would track (similarly) all tasks, regardless of host registered or not, and simply use the MAC address as the linkage of “who”. Not pretty but better than assuming all hosts must also be registered. (Since we did add that feature effectively removing the requirement of Capone Plugin)

@raul You can set all the variables before you call the installfog.sh file

for example if you need to set the IP/Interface you can run:

ipaddress="10.255.20.1" interface="eno2" ./installfog.sh -y

I would take a look at the .fogsettings file to know what variables are checked during install.

There’s likely more that could be set as well, but this is one method you can perform what you want automatedly.

@Infojoe Please try the latest dev branch. this should be fixed.

The issue was simple:

Basically the arguments are stored and from what I could tell, work, but when the HTML side would go to re-display it it would make an input value of:

value="    -Execution -File "[FOG_SNAPIN].PS1""

Do you see the problem?

From HTML side, it would think the string ended at the first double quote.

This has been found and should be fixed in the latest dev-branch.

@meie1kyl Indeed that is a VERY old init

@meie1kyl Now run:

echo $hdinfo

If that houses the right information, we should then know I need to look at the code (on the UI side) to see why its not breaking down correctly

I know it’s a process, I apologize.

We can then just run the fog.inventory shell command too.

@meie1kyl Okay then can you try running doInventory and hit enter as needed?

@meie1kyl I think I need you to run a bit more into the debug:

Can you run:

source /usr/share/fog/lib/funcs.sh
getHardDisk

echo $hd

Basically (just so you’re aware)

I am seeing the drive when manually forced to the NVME drive is properly getting the inventory information for that specific drive, but when the machine boots for deploy/inventory tasks it takes whatever drive is returned from the getHardDisk

So what I wanted tested first was that the command actually worked appropriately and it appears to be working at least.

Next I want to see what the system (in normal operational mode) sees as the main drive.

I don’t know where the problem is but at least it doesn’t seem to be a RAID/AHCI mode switch issue (so thank you for that), it helps paint a bigger picture with real information.

@meie1kyl from that, then can you just run smartctl -i /dev/nvme0n1

@meie1kyl If you’re able to load into debug mode:

Please try:

export hd="/dev/<your_nvme_label>"
hdparm -i $hd 2>/dev/null | grep Model= || smartctl -i $hd | grep -A2 "Model Number" | awk -F ":" '/Model Number:/{gsub(/ /,""); modelno=$NF};/Serial Number:/{gsub(/ /,""); serialno=$NF};/Firmware Version:/{gsub(/ /,""); fwrev=$NF; print "model="modelno", fwrev="fwrev", serialno="serialno}'

Change <your_nvme_label> with the actual nvme label (nvme0n1 or whatever it shows up as)

What is the output?

I have a slightly sneaking suspicion that the NVME is in “RAID” mode and since it’s bios controlled, the machine never actually sees the NVME drive.

@Bristow-0 Just cause I’m a dweeb:

You can simplify this command for reformatting with:

msgfmt -o /var/www/html/fog/management/languages/fr_FR.UTF-8/LC_MESSAGES/messages.{m,p}o

Theoretically. I don’t think it’d cause issues, but explicit is known for sure.

@Bristow-0 I don’t know what OS you’re running:

php-gettext or php-php-gettext is the module you’ll need installed (pretty sure it already is but maybe there’s some unexpected collision occurring?)

If you’re on debian, you my need to also reconfigure the fr_FR.UTF-8 sudo dpkg-reconfigure locales scroll down to the fr_FR.UTF-8 selector and ensure it’s selected.

Tab to Ok, on the next screen choose your default (or change it if you want) and click ok. It shoudl reconfigure the languages.

Other os’s the glibc/lanugage packs just need to be installed.

@Bristow-0 I’m not able to replicate the issue:

@Bristow-0 I’m pretty sure its your systems fonts don’t have a way to represent those particular characters. The encoding displays correctly on my machine looking in a terminal.

I’m assuming this worked, then you did an update and it stopped working? I might look at what fonts recently got updated or removed?

@siarkowski That’s perfectly understandable and much appreciated. Sorry I don’t have a simple “here’s what to do” right now, and maybe a fresh install will fix the issue altogether, but right now it we have limited information. Thank you again for your understanding a patience with this as well.

@siarkowski I understand what you’re saying, what I don’t understand is why this is happening at all. If this was a normal issue, we’d have been notified of this issue probably many many times.

I’m not saying this couldn’t be a bug, I just have no way to replicate the issue in a consistent manner.

Might you be able to pull a backup of your database using FOG Configuration -> Configuration Save -> Export

(After cleaning up the Task issue) and see if you can use a secondary system to import that DB and (as a test) and ensure all the data you require is there (not necessarily the physical images)).

I don’t know what to suggest or say here other than I suspect the database is corrupted and it’s that corruption adding and exploding task records. This (again) isn’t to say there isn’t a bug, but I want try to start with a clean baseline and see if things worked properly under “sanitized” environment.

If a fresh server (if you can share your images that much better) works without adding/exploding the task table, that at least proves it’s a DB Corruption issue. If it, too, starts exploding in task table records, then it shows there’s something in the code that’s doing this unexpectedly but at least we narrowed the scope to exactly where to being looking (somewhere in the task checkin process it seems?)

@siarkowski Thanks, the scheduledTasks you’re showing aren’t showing anything out of the ordinary other than these were “Delayed” tasks

First was delayed to run at 2023-04-19 16:30:00 (UTC)
Second was delayed to run at 2025-03-04 16:30:00 (UTC)

I am pretty sure, this isn’t the issue you’re seeing at least.

So I wonder if there’s some corruption due to running out of disk space that’s causing this?

@siarkowski I’m not aware of anything that might be causing this.

The fact that your taskTypeID == 0 in these cases is interesting.

FOG doesn’t have a “create a new task” from Checking in or anything which makes me think what you’re seeing is a symptom, not a cause.

The way tasks get created is either via UI, API, or (similar to UI/API pair) by having a scheduled task.

We have (although it may need more refinement) checks to make sure that type of task that does get created are valid (of which taskTypeID 0 != valid task)

Can you check your scheduled tasks table and see if maybe something there is doing this at some time?

The fact the task was created at 2026-01-02 09:52:02 looks like it could be a schedule task that somehow has a now invalid task type id that’s just managing to get through.

@lucasgfaj Thanks for letting us know:

I think I’ve found the issue and pushed a code change to try to fix this.

There is a FOS image experimental release that is building currently (2025-12-21) that should contain this once it’s complete. Please download the inits and install them and run a test to see if this is correcting the issue of capture/deploy Multi Partition Image - All disks and let us know if this new version fixes the issue you’ve reported.

Thank you!