Windows 7 multicast
-
AHA!!! The upload is complete and the image file remains in /images/dev/macaddress. Is there a linux process that renames this file and m oves it to the /images directory? If so, perhaps ours is broken. In speaking with the tech, he never really did test fully unicasting the image out as it takes over 8 hours and usually fails, he says.
-
OK, hide the sharp objects
Our latest attempt to upload appears to have worked as the server did finally move it to the /images directory with the proper name. Hence, we can multicast it. The question is: Why??? -
Great to see you got it sorted.
At the end of the image upload, the image get moved via FTP.
For what ever reason, this failed. There are too many variables and not enough information posted to determine why it failed.
If this does fail, you should see on the uploading computer “unable to move /images/dev/blah to /images/foo”. This will continuously scroll on the screen until it can be moved. Did you see this?
-
Oddly, the client did not report any errors. But, now that I know the process behind the move, i have things to check if it fails; permissions, FTP, watch the client closely for errors. Thanks again for your input. It is greatly appreciated.
-
Multicast decided to not be our friend today. <sigh> I pushed up a new image today and it did appear in the /images folder but, alas, it would not multicast either. Some anomalies I noticed:
- Image file was there but not with the correct name.
- The image file seems really small. I had 60 GB of data in the partition, but the file size of the image as around 15 GB. Is there that much compression?
If the image upload is successful, does the system just boot?
-
You should really be starting with Unicast, then working your way up to Multicast. There are so many variables to Multicast (outside of FOG’s control) that can make it unstable and unpredictable.
Uploading is not apart of multicast, so you have another problem there.
Images should be roughly 1/2 the size. So that sounds too small.
Make sure you are running [B]chkdsk /f c:[/B] before you take images up. Filesystem mishaps will cause image uploads to fail unexpectedly.
The machine will reboot, unless you ticked ‘Shutdown after task’
-
Looks like there’s disk errors on our Master which I’m correcting. I did get the original image to unicast to multiple successfully so I’ll work with that for now. Some here think an upgrade from .30 to.32 is a panacea but from what you’re telling me and my observations that may not be the case. Once again, thanks for your guidance and helpful suggestions.
-
I assumed you were on the latest version. That is the first thing to do if you are having problems.
I’m running 0.32 with no problems, as are many others.
If you are still on 0.30 i would suggest upgrading.
The new Web UI is leaps and bounds ahead of the old interface, not to mention all of the other work that makes it more stable.Don’t be one of those people who are scared to upgrade. Trust me, once you upgrade you will wonder why you havent done so sooner.
-
We planned on going there. The issue is that the admin who first installed it used RedHat 2.6.18 and had to heavily modify the install script. Would I be better to build a new server using one of the preferred versions in the install guide and migrate everything over from the existing server or suffer the slings and arrows of an in place upgrade on something that was a bear the first time around? Once again, your advice is timely and expert. Thanks.
-
I would not use RedHat… I have used it a lot in the past, the application support is sub par. I always ran into issues when installing almost everything that hasn’t been specially packaged for RedHat.
I highly recommend Debian (expert) or Ubuntu (easy - built from debian though) as it’s package manager (apt) is leaps and bounds ahead of anything else in the Linux world. They are also VERY strict when accepting new packages, so everything is always in the correct location. (see FHS: [url]http://www.pathname.com/fhs/[/url]). All of this makes both distributions extremely easy to manage.
If you are unsure, i would practice on a VM first, then move to the real thing.
-
This post is deleted! -
Spoke in depth with our senior admin and he said that by following the CentOS install guide, he was able to successfully install on RedHat. He did want me to ask about CentOS compatibility. I offered your suggestion of Debian but he countered with issues concerning iSCSI support for our SAN and other issues. Thanks again for your support.
-
[url]http://fogproject.org/wiki/index.php?title=Installation_on_CentOS_5.3[/url]
I have FOG running on 28 or so CentOS boxes, all are CentOS 5.7 with one exception being CentOS 6.2. They are all very reliable boxes, only issues with install was getting rights correctly set and the hidden .mntcheck file in there. These are by no means server grade machines either they are re-purposed desktops.
-
Thanks for your input.
-
CentOS should work fine and is supported by the installer.
Most admins have a favorite a distribution/religion… i understand
Trying something new is hard, why bother.