Windows 7 multicast
-
We recently deployed 20 workstations using multicasting within the last month, if we try to multicast a new Win 7 image, the client sits at the wait screen and it never starts. If we multicast an old Win XP image, the client starts without issue. We are pulling out the few hairs we have left. Any suggestions or advice is greatly appreciated.
As far as we know, there have been no upgrades or changes to the server. We can push a single copy of this image and it seems to go OK, but we need to image 40 computers and one at a time is not an option.
Thanks.
-
Very strange. Can you provide any more information?
If you look in /opt/fog/log/ there is a file called ‘multicast.log’. Also, if a multicast task is running, there will be another log with more information.
Check here for information on multicast troubleshooting: [url]http://fogproject.org/forum/threads/wiki-troubleshooting-multicast.22/[/url]
Is it Windows 7 32bit or 64bit?
Can you please provide a [B]fdisk -l[/B] dump of your images partition setup? Do this in ‘Deploy Debug’
Just to clarify. If you Unicast Image (regular ‘Deploy’) the machines, they will all image simultaneously; using up all available slots.
-
Your post seems to echo basic troubleshooting for multicasting that isn’t working at all. My issue is a bit unique in that only one of my images (64 bit Windows 7) won’t multicast. I will use your advise, though to make sure that there are no “zombies” out there. The log file may proves informational as well. My other images (XP, Windows 7 32 bit) multicast just fine. So, we’re thinking there’s something about the way fog images 64 bit OS’ that different than 32 bit images or I’m making a really dumb mistake in the image creation that I’m not seeing. Thanks for your input, help from others is always greatly appreciated.
Has anyone out there successfully multicast Windows 7, 64 bit?
Thanks,
-
I honestly wouldn’t see any difference from using x86 vs x64 for a deployment.
I had a similar issue before where a multicast would not start and would hang. The issue turned out to be a corrupt/missing file that was in the /images/ folder on the fog server that related to the particular image. If you can, pop into your /images/ and make sure the full image/folder is in there.
Secondly, what happens when you try a deploy push, as in non-multicast? With the issue I had above, an error would actually appear and ask for input for the image file on the client machine.
-Craig
-
Oddly, I can push one out, but not multicast. The computer getting the image just sits there at “Please wait”. It’s like it’s lost connection to the server. We’re going to try updating our Fog server over the Christmas break to see if that helps. Thanks for posting,
Steve
-
Curiouser and curiouser. I browsed the /images folder on our Linux fog server and do not see the 64 bit images even though they appear on the list and if we push an image to a single computer, it finds it. I started a new upload and do see activity in /images/dev/mac address which I assume is where fog collects the image being pushed. Upon completion, should it be sent to images?
-
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.