[Fog] Multicasting Error

[ind1ekid]

Hey Peeps,

I've got an issue with FOG's Multicasting that I can't figure out, wondering if anyone can help.
I get the error below whenever I try to use the multicasting.

"Can't read the following volume file: ... /stdin.001"

I know the network is fine with multicasting, and FOG creates and deploys single images spot on. Its just I get this error no matter what image I try to multicast, how many machines etc.

I did a bit of googling and didn't come up with much. Though a thread on Clonezilla (which i know nothing about) suggested it was something to do with the disk configuration. Im not sure how relevant that info is, considering its a completely different cloning solution.

Any help would be appreciated.

Sean

Ps. Oh, Ive got Fog 0.28 running on Ubuntu Server 9.10 - (Its a VM, though that should make much difference I guess)

[ind1ekid]

Ok, maybe I can go at a different angle on this: Can anyone share their set up which has been successful at Multicasting images with FOG? Different OS maybe? Filesystem?

[Domino]

When you say you're sure the network is fine with it - how do you know?

Sure ALL your switches support it okay?

[ind1ekid]

When you say you're sure the network is fine with it - how do you know?

Sure ALL your switches support it okay?

Yea, all the switches are Catalyst 2960's and 3650's.
I've had multicast vlc streams in the past, and I can multicast no problemo with Ghost, I'd really like to get FOG functioning to its potential though.

[Mag]

Did you find any solution to your multicast problem? I have a similar problem, looking for a way to solve it.

[ind1ekid]

Did you find any solution to your multicast problem? I have a similar problem, looking for a way to solve it.

I didnt really no.

I was in the process of moving to XenServer from VMWare anyway, so I didnt spend to much time on it, and when I rebuilt my FOG server for XenServer my multicasting issues were gone :| Sorry I can't help you.

[BigDaddyTeemoe]

FOG 0.29 running on Ubunutu 10.10

I ran in to this error while deploying a multicast image to about 4 workstations. It gets to 99% and then:

Volume not found

Can't read the following volume file:
/stdin.001
Enter another full path (directory & name)

After that, there's a field where I guess I'm supposed to enter the new file path and options for "Ok" or "Cancel".

Kind of stuck. Don't know where to go from here.

[tommej]

Is your Fog server handling DHCP, if so is it conflicting with another DHCP on your network?

Check the IP being assigned to the client is being assigned by Fog and not another DHCP server.

[stuwhittaker]

I am also getting this error unfortunately.

In the logs it looks like this client times out just before the process is then started.

They are being casted through 2 different switches and it worked when the machines were all plugged into the same switch.

Running for v0.29 and Ubuntu 10.04

It would be useful to find a solution to this

Cheers
-Stu

[BigDaddyTeemoe]

I've tried a couple of different scenarios. But it was always in Win7 where the netdom path either wasn't installed or the fogservice netdom filepath was set for xp rather than Win7. This was in the first month I had ever been introduced to FOG or anything like this, before I understood how it all worked. I'm going to start trying it again, as I have to re-image some of the machines for updates, this time on a static network with Fog0.30, which doesn't use netdom. I'll update whatever I figure out.

[stuwhittaker]

BigDaddyTeemoe, over the last few weeks I have been using FOG version 0.30 and not once had a successful multicast over a physical network. It has only ever seemed to have worked to virtual machines (at that is it multicast as they were travelling down one switchport!).

I would stick with 0.29 personally but good luck with 0.30 if you do decide to go down that way.

Cheers
-Stu

[BigDaddyTeemoe]

BUT, to answer the solution to my previous problem, yes, I fixed it. It was a combination of two things:

1. Image type - I had the image type set to "Multiple Partitions - All Disks" instead of "Multiple Partitions - Single Disk." I don't know why, but in 0.28, All Disks worked. But in 0.29, we had to change it to single disk.

2. File Permissions - My supervisor came in one day and said he, "Changed some stuff on the server." Which typically means he broke something. His solution when something goes wrong is to completely format the whole thing instead of tracking down the problem. He would then copy the compressed image files into the image directory, BUT when he did that, he didn't change the ownership of that directory to /root. I think it's something like:

sudo chown root:root /images/[imagename]

or

sudo chown -r root:root /images

The first changes only the image folder you specify, the second changes anything in the /images directory. If you try to do this from the "properties" menu GUI instead of in the command terminal, it probably won't work. Also, a lot of people said they used "chmod 777." This also didn't work for me.

[stuwhittaker]

Thanks very much,

I shall give your suggestions a go tomorrow By changing the image type, from what I remember I have already given the whole of that directory root access but will check also.

Did you have it successfully multi-casting to computers plugged into different network switches?

I shall post my findings

Cheers
-Stu

[BigDaddyTeemoe]

Our network configuration is put together with duck-tape and popsicle-sticks. The way I have to set it up is with multiple Linksys 8-port switches on a stand alone network which means no AD integration. So, yes, I can get it to work across multiple switches, BUT, they're pretty basic switches. So if you had something where you can make certain ports only talk to specified other ports, you might want to check that out.

It's been a while since I've had this problem, but when it runs the stdin.001 error, is it after the image has downloaded to the machine and at 99% it shows this error? Or does it happen before it even tries to download the image when its mounting drives and what not? If it's the former, it's probably a image type issue. If it's the later, it's probably an ownership issue.

[stuwhittaker]

I get you,

It happens before the multicasting process starts. From looking at the logs it registers the clients joining the session and then it waits a short time.... one of the clients drops out and it states it is disconnected in the log. The multicast image is started but only with the one machine (I am currently only multicasting to two machines on two different switches)

Both switches are managed layer 3 48port buggers so may need to check some config within them Not got that far yet in the investigation as I was using v0.30 with no success.

Suggesting its an ownership or timeout issue.... I remember seeing someone with a similar issue and change the MySQL connection timeout to something higher. I will try this and your suggestion and report back

Thanks for your help BigDaddyTeemoe

-Stu