Posts made by Tom Elliott

And you’re sure this is specific to FOG rather than Hardware?

What version of FOG are you running?

Have you tried other kernels?

Like I said, my pigz corrupt was because my kernel on that server dumped in the middle of operating.

I’m just trying to help narrow down the issue, though I think trying to get the error debugged on your server is important.

Yes please, and reenable task reboot. It’ll help be debug this issue.

Also,

It’s correct that it won’t install unless you’re logged in. The administrator access needs to be there. I don’t have the source to rebuild the dll’s in use so that particular issue is still the case.

Do me a favor, update to r1152. I added an element to jobs.php service function that checks if the job is valid and is not a snapin deployment reboot, otherwise there’s no jobs to perform.

The original method was, if the tasking is valid, reboot the system so hopefully this will help you out.

I’ll take a look. I think I disabled task reboot on my fog server (globally) and all seemed to work much more betterer.

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.

What I mean, is there tasks for this pc such as a Download/Upload/Multicast.

Do you have tasks awaiting action?

Do you update SVN to the most current?

Should be fixed in r1151.

Already released. Basically checks and set’s host.

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.

Greg,

If you’ve downloaded through svn, perform an update and reinstall. I found a bunch of issues and corrected them.

Currently we’re on 1150, but I’m guessing you’re a few revisions behind.

Ricardo,

Can you give a shot at my kernel?

[url]https://mastacontrola.com/fogboot/kernel/bzImage[/url]

It shouldn’t rely upon system/device specific frame buffers and in theory would work on your system. If it doesn’t I’ll add mtrr support into the kernel, if you’re willing to test.

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.

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.

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.

If you’re trying to upload an image, why is it sending inventory?

Perhaps more detail,

What kind of imaging? Download, Upload, Single Disk Resizable, Multi-Part Single Disk, Multi-Part-All Disk, raw/dd? Multicast?

It looks like the 3com switch is a managed switch, but I don’t think that’s quite your issue.

As you state the static IP Changed from 192.168.0.200 to now, 192.168.1.200, is all of your FOG stuff pointing there, and is option 66 pointing to the new server.

Option 66 on the DHCP Server should be, now, set to the new IP address of the FOG Server. This should give you back pxe menu.

In the FOG Management side of the house, you’ll likely need to make the changes to Storage Management->Storage Node, FOG Configuration (Other)->FOG Settings-> FOG_TFTP_HOST, FOG_PXE_IMAGE_DNSADDRESS (This will probably be the new Dlink’s gateway address.), and FOG_WEB_HOST.

Did you install FOG with or without a DHCP Server?