Uni-cast deployment problem

[TheeGrizzly]

Hello, im running Fog .32 on ubuntu 12.04,

I have been imaging fine all along, my tftp quit the other day, so i brought that down and back up and was able to upload images. However now when i try to deploy an image i get an error

[CODE]Can’t Read following volume file:

images/780/dlp2.img.001

Enter another file path or directory.[/CODE]

I have tried this with 3 different images and created a new image and I’m still getting the same error.

Does any one know a cause or solution for this problem?

[TheeGrizzly]

please help

[Tom Elliott]

It sounds like the file /images/780/d1p2.img.001 does not exist? Can you very if this is indeed there?

[afmrick]

We started having the same problem today on 0.32. There’s a “d1.mbr” and a “d1p1.img” but, not a “d1p1.img.001” for any image in their directories.

-rwxrwxrwx 1 root root 512 Jun 2 13:16 d1.mbr
-rwxrwxrwx 1 root root 77976571904 Jun 2 14:30 d1p1.img

If I re-type the path into the error box, omitting the “.001” part, it’ll finish imaging and boot normally. …We can’t do that several hundred times though.

[Wayne Workman]

@afmrick

That’s very interesting. Another guy is having the exact same issue (I think), but he’s found another work around (equally unacceptable in nature though).

Try making a simbolic link to /images/780/d1p2.img.001, pointing at the actual files… I bet it’d work.

[CODE]ln -s /images/780/d1p2.img /images/780/d1p2.img.001[/CODE]

Then ensure the sym-link has the right permissions:
[CODE]chmod 777 /images/780/d1p2.img.001[/CODE]

If that works for you, we can build a script that can do this for all of your images in mere seconds.

Let us know, I’m very interested.

[Tom Elliott]

To my knowledge, 1.2 and trunk versions of fog do not have this type of bug. I’more partial towards trunk only because it is what I’m developing on and has many bugs and improvements over 1.2. That said, I think if you were able to update to 1.2, you’d find any of these weirdness issues would be gone.

[Wayne Workman]

I agree with Tom.

I’d recommend upgrading, too. I was just very curious about the issue you were seeing.

[afmrick]

Oooh, the symbolic link would be a pretty neat work around! Thanks Wayne!

Sadly and/or stupidly I finally noticed that our partition for the FOG images was full and that appears to have been causing the problem. …So many clues.
I’ll know for sure in a few hours.

[afmrick]

Oh and the upgrade to the current version is in the pipeline. We just did so much customization on 0.32 that we’re moving a little slow on upgrading.

[Wayne Workman]

@afmrick said:

Oh and the upgrade to the current version is in the pipeline. We just did so much customization on 0.32 that we’re moving a little slow on upgrading.

If you want support for open source projects that have limited volunteers / developers,

Customization is a no no, unless you really know your stuff lol. Try to stay the beaten path, do things the way others have done it.

I.E. no crazy distros that nobody has heard of, No crazy “multi-purpose” linux servers that do a million other things besides FOG… gah…

And have backups of your images and your database… regularly.

[Wayne Workman]

@afmrick

So, you’re not going to worry about this problem anymore because the disk is full and you’re upgrading Distro and FOG ?

Is it ok for me to mark this solved?

[afmrick]

Well, I’m all good. ThreeGrizzly originally posted the problem.

[Wayne Workman]

Well with FOG 0.32, the answer is to upgrade to 1.2.0.