Posts made by Tom Elliott

I’m trying to look at the issue.

I didn’t change to the new scripts until: r1142

In r1140 to r1141, I changed the files:
change/trunk/packages/web/lib/pages/HostManagementPage.class.php (diff)
change/trunk/packages/web/service/mc_checkin.php (diff)
change/trunk/packages/web/management/reports/User Login Hist.php (diff)
change/trunk/packages/web/service/Pre_Stage1.php (diff)
change/trunk/packages/web/service/usertracking.report.php (diff)

None of those files deals with Windows services except the usertracking.report.php file, which only deals with logging who’s logged in when.

It’s the only thing, windows related, that I could think of as causing your particular issue.

/opt/fog/log is for the three FOG Services installed (FOGScheduler, FOGMulticastManager, FOGImageReplicator)

/var/log/{httpd,apache2}/{error_log/access_log, error.log/access.log} is the right places to look, but it seems strange.

Is there an actual task in place on the FOG GUI for your upload task?

I haven’t seen any issues with SDR deploy of xp, as it’s all I’ve had to test with for the last few weeks (from an xp standpoint), and as far as I can tell, the fog.capone script has it’s own checks/balances, but ultimately call’s upon the main fog script. Can you try registering one of your systems and deploy the XP image that way?

It, by itself, is nothing to be worried about. You can remove those entries from the database, as they are a nuisance. I’ve updated the trunk and this should be fixed.

I haven’t, quite, figured that out yet. I get those as well. It seems to be something from the Capone plugin causing the issue.

Actually, it appears to be the way the method is called.in the ServiceConfigurationPage.class.php file. I’m checking if this is correct.

r1155 should have fixed the hostname_early issue, but I don’t know if just turning it off has helped you out at all.

I’m resubmitting another release, should work, (but no guarantee’s) on hostname_early.

What do the error logs say on the fog server?

So it never actually imaged and just stays at checking in?

I think I know why. Can you disable HOSTNAME_EARLY on the fog server and try again?

I “fixed” HOSTNAME_EARLY, but it seems to me your systems are sysprepped already, so a hostname change isn’t the right way to go.

Please step up in one increment at a time. I want to narrow down the exact nature of the bug. This is awesome.

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.

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.

r1154 should fix windows xp multicast deploy issue.

Replace that file with the one posted here.

[url=“/_imported_xf_attachments/0/521_inventory.php?:”]inventory.php[/url]

r1153 should fix the $this variable call in the capone.php file.

Those errors are normal. But you’re still not getting the tftpserver running properly?

I think I put the new fog scripts in place at revision 1145, maybe to to 1140?

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.

If you revert the revision and try does all work again? To revert run svn -r1150 update and perform reinstall.