Latest FOG 0.33b
-
It’s possible the drive containing your images is corrupt and needs a check?
Also,
Just so all are aware, I’ve found an issue in Windows XP imaging as Multi-part images. This may be what the problem was in 0.32 as well, though I’m not too sure.
As I stated, I’ve never had any luck imaging (Upload Specifically) Windows XP as multi-part. It would start, the upload would never happen, but would switch, after checking in, straight to Task Complete, then reboot. It does the same on 0.33b, but I think I’ve figured out the issue. I don’t have a proper fix for it, but I am currently uploading the image, so it’s still in testing.
Basically, what seems to happen, is fog tries to check the partitions, but the method WIndows XP used/uses to create the partitioning table, it places bits of data outside of the actual partition table. For this reason, the fogpart --list-parts $hd command never returns with any valid partitions, it actually reports (Can’t have partition table outside of disk.) Which is normal if we’re trying to deploy an image with a smaller hard-drive than the uploaded image originally had.
It seems to me, that the fix is to delete the partition (not the data) and regenerate the partition so we can actually upload the image. I’m currently testing, but hope this issue will not be too enforcing as Windows XP support goes away in April from Microsoft.
-
[quote=“Tom Elliott, post: 21983, member: 7271”]If you’re trying to upload an image, why is it sending inventory?[/quote]
Sorry, the problem is when I make quick inventory from grub fog menu, not the image upload
-
Should be fixed in r1151.
Already released. Basically checks and set’s host.
-
I just got the pigz corrupt issue. On my end, it’s because my storage server system had a kernel segfault and cut communication between the hosts and the image store.
-
Ok the image is copying back over to the site now (takes about 3 hours I am 1 hour in) so if it still happens after what should I do.
-
I’m just trying to help narrow down the issue, though I think trying to get the error debugged on your server is important.
-
Like I said, my pigz corrupt was because my kernel on that server dumped in the middle of operating.
-
ok I will take a look.
-
it is looking good since I resynced the image to the server currently at 10% will let you know once it finishes
-
The image finished successfully. Thanks Tom.
-
Hi Tom, testing capone on r1152.
client hangs at looking for images, with the following error in the apache2 error log.
[Tue Jan 28 18:26:57 2014] [error] [client 192.168.3.12] PHP Fatal error: Using $this when not in object context in /var/www/fog/service/capone.php on line 10
[Tue Jan 28 18:26:59 2014] [error] [client 192.168.3.12] PHP Fatal error: Using $this when not in object context in /var/www/fog/service/capone.php on line 10
[Tue Jan 28 18:27:01 2014] [error] [client 192.168.3.12] PHP Fatal error: Using $this when not in object context in /var/www/fog/service/capone.php on line 10
[Tue Jan 28 18:27:03 2014] [error] [client 192.168.3.12] PHP Fatal error: Using $this when not in object context in /var/www/fog/service/capone.php on line 10Any thoughts
-
Will fix, it’s my mistake. I made a typo in working with all the classes, the service files are not class objects, so that’s why you’re seeing that error. Will fix shortly.
-
r1153 should fix the $this variable call in the capone.php file.
-
r1154 should fix windows xp multicast deploy issue.
-
Working off of a theory my XP multi-part style images, it appears that the xp.mbr file provided is set to a larger drive, this is why we’re seeing the can’t have partition outside of disk issue. The vm’s i’m working in only have 50GB available, but the MBR Table looks to set a drive of 75 GB. Because I’ve tested imaging single disk, many a time now, my XP image partition table is for the 75 gb drive, which is what was causing my issues. Looking into a little further.
-
Currently uploading multi-part xp image. Had to fix the partition table so the partitions wouldn’t overlap any more. I don’t know of realigning the partitions broke XP yet, but will keep you posted.
-
Thanks Tom.
Now getting a bit further, hangs at checking in on the client.
Nothing in apache2 error log, but lots of
192.168.3.12 - - [28/Jan/2014:20:41:02 +0000] “POST /fog/service/progress.php HTTP/1.1” 200 343 “-” “Wget”
192.168.3.12 - - [28/Jan/2014:20:41:03 +0000] “POST /fog/service/progress.php HTTP/1.1” 200 343 “-” “Wget”
192.168.3.12 - - [28/Jan/2014:20:41:03 +0000] “POST /fog/service/progress.php HTTP/1.1” 200 343 “-” “Wget”
192.168.3.12 - - [28/Jan/2014:20:41:03 +0000] “POST /fog/service/progress.php HTTP/1.1” 200 343 “-” “Wget”in access.log.
[url=“/_imported_xf_attachments/0/522_boottest.png?:”]boottest.png[/url]
-
So it never actually imaged and just stays at checking in?
-
What do the error logs say on the fog server?
-
Yes, it just sticks at checking in, I wouldn’t expect it to stay there for more than a few seconds, but I’ve left it for minutes.
I’ve just tried task uploading and deploying of a working XP system, the deploy seems to work OK, but on the reboot fails with a BSOD unmountable boot volume, so it looks like XP, single partition resizable has problems.
Disc is 30Gb, on virtual box
Apache 2 has nothing in the error log, access.log has repeated messages as per my previous post.
/opt/fog/log is empty, and I can’t see anything in the log viewer under fog settings.
Am I looking in the wrong place for fog logs, or do I need to turn logging on?
Thanks