hard disk information vanishes after deploying/download from client inventory

[tian]

Now in git5572 - and I’m sure before also - the hard disk information (Hard Disk Model, Hard Disk Firmware, Hard Disk Serial Number) vanished after deploying/downloading a client computer (with the new fog client). Other information is still there (recreated?).

I can update the hardware inventory by an advanced task, but then after deploying/downloading once more the hard disk information is gone again.

[Tom Elliott]

I don’t understand what the issue is, at all.

All tasks update inventory as they’re generated, so I suppose it’s this that’s erasing the HD information? I don’t know for sure though.

It’s not necessarily a “bug” but I need some more help in regards to tracking why it’s not working.

[tian]

@Tom-Elliott I’ll try to explain the problem in a better way:

The hard disk information I can see vanishing from: selecting a host -> host menu -> inventory -> where i can see the “Host Hardware Inventory” page
(The fog address looks like this: http://FOG_SERVER_IP/fog/management/index.php?node=host&sub=edit&id=21#host-hardware-inventory)

Here are the steps to see the behavior:

• at first I let the hardware inventory task run to get all possible hardware information of a host
• after a reboot of the host the hardware inventory task is running and I can see all the hardware information of this host in fog (including “Hard Disk Model”, “Hard Disk Firmware”, “Hard Disk Serial Number”)
  – (the entries “System Version”, “Motherboard Asset Tag”, “Chassis Version” and “Chassis Asset” are empty though)
• after successfully imaging/deploying this host (with new fog client 0.97 + AD join, snapins …) the three hard disk information entries are empty/gone from “Host Hardware Inventory”
  – the other hardware information is still there

To get the hard disk information back after every imaging I need to rerun the hardware inventory task.

I hope this is better to understand. If some more information is needed I’ll try to get it.

[tian]

some more information - the hard disk information is already gone when partclone is still working on the host.

Here is a screenshot of the database with the last update times (during partclone is still running):

I created the deploy task at 3:02:12pm and the imaging has began at 3:04:15pm - the same time imaging began, the table “inventory” (like you guessed before) updated and the hard disk information for this host was gone after this time. Another host (not deploying this time) kept its hard disk information.

[tian]

@Tom-Elliott The hard disk inventory information is still vanishing in git6907 when the imaging process is started with a deployment task.

All hard disk information has been correctly added before by a hardware inventory task (also with git 6907).
When uploading/capturing an image it doesn’t delete the hard drive information.

[Wayne Workman]

@tian Thank you for following up on this, we need to see about getting this fixed.

Anything special about the computer this is happening on, or is it all models?

And I know this is going to be a very long-shot question but do you know about when the HDD info started getting cleared? What FOG revision number?

[tian]

@Wayne-Workman The computer models I use for testing the trunk versions of fog at the moment are all the same model/product from the same manufacturer- so all have the same Mainboard, CPU, BIOS version, BIOS settings, … just the hard disk models are from 2 different brands (but same size). When experimenting some time ago with an iMac (only one for up/-downloading) I think there has been the same behavior.

For the question about the revision number - I’m not 100% sure about it, but I’ll try to remember as good as possible:

• From what I remember I started experimenting with the iMAC around May last year for some time, so the problem could already have been there there in svn revisions 34xx to 37xx.
• Between svn37xx and svn4457 I remember I checked a few times if the problem still exists, but couldn’t search more deep into this at this moment. With git version 5572 (svn4457) I began to search for the moment in the deployment process where this is happening.
• before the trunk versions there was also FOG 1.2.0 running for a short time - but I didn’t pay attention to hardware inventory back then.

[Sebastian Roth]

@Wayne-Workman The issue is very easy to reproduce… I am not sure if I better cry or laugh out very load. Why didn’t anyone else report this before? As I found out just now the HD infos were wiped on deploy pretty much ever since. Well I didn’t go back to 0.32 but I just verified that this problem existed in FOG 1.2.0 already (possibly even earlier?!).

@tian I am very sorry that we didn’t look into this earlier. Back when you reported this first most probably some other major issue came around the corner and kept us busy and we forgot. Too bad. As this has been there pretty much forever everyone has lost his HD inventory infos anyway. So it wouldn’t have made much difference. Thank you so much for pointing this out again!!

@Tom-Elliott And here is my patch proposal (tested):

diff --git a/src/buildroot/package/fog/scripts/bin/fog.download b/src/buildroot/package/fog/scripts/bin/fog.download
index ff66c6e..396d163 100755
--- a/src/buildroot/package/fog/scripts/bin/fog.download
+++ b/src/buildroot/package/fog/scripts/bin/fog.download
@@ -6,6 +6,7 @@
 . /bin/fog.checkmount
 . /bin/fog.checkimgvar
 imagePath="/images/$img"
+getHardDisk
 origmac=$mac
 mac=$(getMACAddresses | base64)
 . /bin/fog.inventory "true"

[Tom Elliott]

@Sebastian-Roth it can’t be that simple can it?

[Tom Elliott]

So @Sebastian-Roth’s findings were correct. I always check for the HDD during the tasking, but the inventory updating was happening BEFORE the hdd was acquired by the system. I have since fixed this by doing a little different than suggested. Basically, I made the inventory task run through the inventory script rather than a sub component of the fog.auto.reg script.

Hopefully this is safe to solve now. Sorry I’m such a dummy.

[Tom Elliott]

I’ve solving in the hopes that this is indeed fixed now, please just keep us informed.

[tian]

@Tom-Elliott @Sebastian-Roth I just did a quick test with svn5107. Right now a deploy task has been running and the hard disk information has been kept. Tomorrow I’ll test some more and report back if there is still something wrong, but it looks like it is OK now.

Thanks everyone for fixing this.