@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.
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:
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:
@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.
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:
Changing “Image Type” to “All Disks” is working OK:
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?
Some change between git5221 and git5283 seemed to have solved the hostMAC table problem.
I cant see the increase anymore in git5283. Since the hostname changer service seemed to be related to it I tested the AD join and it still seems to work fine.
I’ll test some more, but it looks good now.