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

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

@Tom-Elliott @Sebastian-Roth sorry for the late reply - I now tested it with git6907 and the display is fine now.

Also thanks for correcting the hard disk related prefixes to binary.

@Tom-Elliott An old and the newly created image (without and with “d1.mbr”) have been deployed fine with version 6651. Thanks for fixing it that quick.

I just wonder why installing version 6547 again didn’t fix it before.

@Sebastian-Roth

Could be something different causing this - but for me is like I described before. Before I updated to git6609 I deployed the image with git6547 for a whole group, (unicast). An image created with a older git version also has no “d1.mbr”.
Even going back to git6547 didnt’ resolve this issue ( a simple reinstall, because there has been no database structure update since then)

Was there a change in how images are created recently? Because option 2 (Windows 7, Single Disk, Multiple Partions) is always used to create images.

I had the same error with git6609 and git6621 - the image I had the error with, was created with git6547.

I tried a lot with ftp and other things, but in the end I think the update to git6609 deleted the “d1.mbr” files for all of the images. No image has these anymore (Single Disk, Multiple Partitions).

A newly created image (with git6621) is deploying right now without this problem.

The next days I can try if updating to a newer git version deletes the “de.mbr” again and report it back.

Hi,

the amount of data written and size of the partition/hard drive (160GB/149GiB) are displayed twice (in a different order and capped by the first digit of hard disk size i think) in the status bar with mouse over:

The image deployed is “Multiple Partition Image - Single Disk (Not Resizable)” in unicast mode.
The fog version used for upload and download was svn4929 (git6547), but the display was like this in some more early (fog 1.3) trunk versions.

Maybe it also would be possible to show the total amount of data to be written instead of the disk size and display GB and GiB correctly if it is not too much to change.

Thanks.

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.

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

@Tom-Elliott Thanks for fixing the two other bugs also. I’m on git5662 now and it is working again.

And something other worth mentioning:
It is a great change that the state in the snapin log is now displayed as “complete” instead of “4” - this makes things more clear.

@Tom-Elliott Thanks for the (partly) fix. The good news: I’m now on git5618 and the warning from the web page are gone now.

But the bad news: the other 2 bugs (backslashes in csv export and not be able to create pdf export) for the snapin log still exist.

errors are still there in git5612 - from apache error log:

[Thu Dec 03 09:29:53.144110 2015] [:error] [pid 1458] [client MY_IP:55385] PHP Warning: mb_convert_encoding() expects parameter 1 to be string, object given in /var/www/html/fog/lib/db/mysql.class.php on line 152, referer: http://FOG_IP/fog/management/index.php?node=report&sub=snapin-log
[Thu Dec 03 09:29:53.148772 2015] [:error] [pid 1458] [client MY_IP:55385] PHP Warning: mb_convert_encoding() expects parameter 1 to be string, object given in /var/www/html/fog/lib/db/mysql.class.php on line 152, referer: http://FOG_IP/fog/management/index.php?node=report&sub=snapin-log

In the file “/var/log/php5-fpm.log” I just can see some of these messages:

NOTICE: configuration file /etc/php5/fpm/php-fpm.conf test is successfull

The number of warnings seems to be related to the number of snapin log entries returned for the selected date range.

Should I check/try anything else?

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.

There seems to be a problem with snapin log:

• Getting the snapin log after selecting the start and end date the following appears:
  
  The snapins listed below this are displayed fine though (I just cut the screenshot there).

• exporting the csv works, but the “snapin run with” content has some display error (on the web interface and in the database the backslashes are displayed fine with just one between drive letter, folders and file):
  

• Trying to export the pdf the following page appears:
  

The snapins executed fine - return code was 0, state was 4.

The imaging log seems not to have these error and works fine (display web page, export csv and pdf).

I think I had this problem with fog 0.32 also. Does fog stay logged in when you let a tab with the logged in fog home screen (with the graphs) run all the time and open new/other tabs for working with fog? (Didn’t monitor fog 1.2 and svn versions for this problem yet)

@Tom-Elliott Since I just use “c:\windows\system32\cmd.exe” in “run with” to run batch files there should be no surprises with other snapins for now.
And knowing the “workaround” to fix existing snapins (that won’t run) by simply updating them, there is no problem left at the moment related to this topic.

@Tom-Elliott Thanks! It is working now.

In git5499 the saving/updating of the snapins in working again without adding more and more backslashes.

But the snapins only run ok after updating them. Even when the backslashes were displayed ok (with 1 backslash between folders and file) it seems to be necessary in my case:

• existing snapin with “run with”: c:\windows\system32\cmd.exe
  – exit code “-1”
  – from client log: “RunWith: c:windowssystem32cmd.exe”
• after updating the same snapin on the web interface (without changing anything)
  – exit code “0”
  – from client log: “RunWith: c:\windows\system32\cmd.exe”

@Tom-Elliott
at least in git5473 and git5483 the backslash update behavior described by Claude Girard happens to me in “Snapin Run With”.

I tried to remove all the backslashes and update - but it is getting more and more.

The weird thing is, that the snapin still runs fine on the client (0.9.7, git5483) even the client fog log shows all the backslashes in the “run with” path.

• Return code is 0
• snapin status is 4
• changes the batch file should do have been made

It still would be great to get rid of all the backslashes.

(fyi: in git 5473 return code of the same snapins was -1 and the client fog log missed all the backslashes at the “run with” path)

@Tom-Elliott Thanks Tom.

Uploading an image with “Multiple Partition Image - Single Disk (Not Resizable)” is running right now.
Guess it solved the problem. If there is any problem at the end of imaging or when downloading I’ll report again.

Uploading a Image with the settings:

• default: Windows 7
• Multiple Partition Image - Single Disk (Not Resizable)
• Everything
  seems not be possible.
  This is the last screen I can see before the computer restarts:
  
  The “Image” size displayed in the image overview is 31.5KiB and only the MBR seems to be uploaded to the image directory. The capture task on the web interface is gone and on the main page the daily counter is increased by 1.

Changing “Image Type” to “All Disks” is working OK:

• default: Windows 7
• Multiple Partition Image - All Disks (Not Resizable)
• Everything
  This is the last screen I can see before partclone starting to work:
  
  The upload is OK and I am able to image this to another computer.

I tested the function of TFPT guided by the wiki entry without problems.
The computer has only one hard drive and one DVD drive. No other SATA devices.
The computer I’m trying to capture from is only used for upload/capturing and it was working some time ago with the “Multiple Partition Image - Single Disk (Not Resizable)” setting. (It’s our default setting for images)

Are there any more information needed to solve this problem/bug?