@sgennadi Can you please provide more information on this?

Is this still happening in the latest 1.6?

I’m asking mainly because I’m not sure what is happening:

What I think I see:
On image create task gets ready to complete after doing the data gathering:

It correctly removes the /image/<imageNamePath>
It does NOT move /images/dev/<macaddress> -> /image/<imageNamePath>

So a work around exists (as annoying as it may be) that you can manually move the /images/dev/<macaddress> to the image name and that will still work though I agree it should be automated.

I believe 2141 may have been early on in the moving toward SSH purely for handling image moving and I would hope that this problem is addressed in newer files.

@FOGBreaker101 over the last couple of days we found there was a bug in fog that could create required items inappropriately. We made some code to try to prevent that altogether, as well as fixed the issue directly causing the bug. This showed us some other bug(s) and likely we’ll get more reports of new bugs yet. But hopefully this helps explain the why it happened.

It did get us to make better logging and functionality of the pdodb class so all in all a worthwhile improvement.

@FOGBreaker101 Please update and try again.

I am not 100% sure what the actual error is, but what I’m seeing from a DB standpoint there is a totally different issue occurring and that I could work around.

Can you try to update and try again? If you’re still having an issue and I can try to take a look.

@Tom-Elliott Figured it out, please update and try again, apologies:

Trying to account for bad information in the DB and it was stated that imaging log required type and finish time, since these aren’t defined at check in, they shouldn’t be required.

THanks for letting me know.

@sgennadi Can you show me yoru history table?

it should show what’s happening or some piece of information relating to image log creation.

@sgennadi please pull and try again.

It seems theres a new requirement for NFSLastMemberID which wasn’t being set in the create tasking. While it should’ve errored appropriately it was being hidden. The History show a “succes” entry but with a 0 id which isn’t any good anyway.

Cleaned up the PDODB class a bit to help more clearly state what the issue is and cleaned up a couple other things as well.

@Infojoe They are one in the same lol and you’re welcome.

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