@AlexPDX said:

i see u did not find the time to fix the M.2 NVMe problem 😐 …and the Storage Nodes being Unauthorized 😐

No, we haven’t yet. You are very welcome to get involved and help fix this stuff.

@Sebastian-Roth said in Windows Keys Management Plugin:

overwrite each others settings

Yess…this was the cause …i’ve uninstalled the plugin and now all seems ok 🙂
10x dude 💪

@AlexPDX since also the computer names are known it should be possible to add it to the database.
But it would not make much sense because when running a Hardware Inventory task or deploying a client (where also a Hardware Inventory task is run automatically) I think the data would be removed from the database.

To have the data in the fog database permanently I guess we have to wait untill FOS is able to get this data by itself and add it to the database.
For now to get the SSD model data without accessing each computer physically and have it in one place is enough for us to check for possible firmware updates, run the firmware updates and re-check if the updates were applied correctly.

@AlexPDX Which version of Windows do you use exactly?

We had reports about what sounds similar to what you say not long ago.
https://forums.fogproject.org/topic/15258/windows-10-and-fog-product-key-problem-20h2
https://forums.fogproject.org/topic/15256/win-10-pro-product-key-not-installed-probably

I am still not sure if this is something the fog-client is doing wrong (we just use the slmgr.vbs calls that worked for a long time) or if it’s Windows preventing it from happening.

@AlexPDX When I looked at this on the smartphone earlier today it did not load the second picture and so I misunderstood the issue. The master nodes sends a HTTP request (URL http://x.x.x.x/fog/status/freespace.php?path=/images) to the storage node to get that information. The storage node checks if the given path exists, is readable and a directory. If not it returns no values.

So your link /images -> /home/fogproject/images is causing the issue. Linking can be somewhat hideous and I would never advice anyone to link to the images directory just to mask that it was setup the wrong way in the first place.

I suggest you move all the content from /home/ to a temporary location, re-mount that partition (/dev/mapper/centos-home) into /images and move all the stuff you had in /home/fogproject/imagesover to the new/images` (residing on the extra partition.

@AlexPDX said in Location Plugin Not Working as it should ...:

So…i had to instal phpmy admin and find that there wos a problem in the data base …

What exactly was the issue? How did you fix it?

@AlexPDX So if you look on the storage node(s), are those image files there?

@AlexPDX said in Storage Group and Storage Node explained for dummies:

1.5.8 keep remembering the Windows Keys in the Host

Yes that info is stored in the database. With that said, the upgrade should not erase keys. If it does then there is a bug in the upgrade script. AFAIK nothing is ever deleted from the database during an upgrade. A schema change will add or remove fields but not data.

It’s done …I have completely installed the virtual machine but also the fog server with the latest version, at the moment it seems that everything works just fine, I managed to capture the image of windows 10 with MBR, also did a full inventory of the work station , i deployed it on another workstation … momentarily I’m with kernel 4.19.36 … I’m thinking to update it at 4.19.48 … but I doubt it will not come up with the same problem … however i will try anyway 🙂
10x for the help ! …specialy @george1421 but also @Tom-Elliott ( apparently the problem started from the location where my images are saved…bad cfg )