Latest FOG 0.33b
-
If you’re trying to upload an image, why is it sending inventory?
-
[quote=“Tom Elliott, post: 21974, member: 7271”]Perhaps more detail,
What kind of imaging? Download, Upload, Single Disk Resizable, Multi-Part Single Disk, Multi-Part-All Disk, raw/dd? Multicast?[/quote]
Sorry for the dalay I am trying to download an image it is a single disk Windows 7 image so it has two partations. It restores the 100mb partation fine then gets to about 2.51% before it errors out with “PIGZ abort: corrupted input – invalid deflate data : <stdin>”
-
Is it multicast, and if so, how many systems are in the image job?
Is it unicast, and does this same image work on other items. I’ve not seen this issue yet. I’ve tested upload/download, multicast, etc… and had no issues.
-
I am just trying to image one hyper-v machine the same imaged worked before with no issues. I may try to use the back up copy I have to make sure it did not get corrupted, but the image size and stuff looks fine.
-
I’m just trying to narrow down the issue.
I find it unlikely that my changeover has caused a corrupt data on your server, though there could be a typo in the new script that’s causing the issue.
That said, I’ve tested Single Disk Resizeable, download and all seems fine. I’ve also tested, Single Disk Resizeable upload, and all seems fine.
I’ll test some more again. I’m just using windows xp as my test, but will try a windows 7.
-
ok and Ill test what I can on my side.
-
Windows 7 seems (Single Disk Resizable) seems to work fine. I’m currently at 14.14% complete. Once it’s complete, I’ll perform a download of Windows 7 multi-part single disk to see if that works, then I’ll do the same image set as multi-part all disk. Then I’ll perform the same download through multicast. This should work out the kinks of the download script. I’m also doing the same for a windows xp image. Though I’ve never had any real luck with multi-part and windows xp, even on 0.32, I’ll give this a shot as well.
-
[quote=“Tom Elliott, post: 21989, member: 7271”]Windows 7 seems (Single Disk Resizable) seems to work fine. I’m currently at 14.14% complete. Once it’s complete, I’ll perform a download of Windows 7 multi-part single disk to see if that works, then I’ll do the same image set as multi-part all disk. Then I’ll perform the same download through multicast. This should work out the kinks of the download script. I’m also doing the same for a windows xp image. Though I’ve never had any real luck with multi-part and windows xp, even on 0.32, I’ll give this a shot as well.[/quote]
You may not have to I have tried on on another system same revision and it seems to be working some how my image might have got corrupted I will copy that image to the server where it is not working and see if it works.
-
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.
