Latest FOG 0.33b
-
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.
-
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.
