Image drop issues after upgrade from 1.3.3 to 1.3.5
-
SERVER FOG Version: 1.3.5
OS: Ubuntu Server 16.04
CLIENT OS: Windows 7 and 10
DESCRIPTION
After update from 1.3.3 to 1.3.5, I can’t deploy my old images I receive following error:
An error has been detected!
No source file passed (writeImage)
Args Passed: /dev/sda1
When you look at the Web UI, it says that the image has 0 bytes. I can see on the server that the image files are there. I looked into the problem and found that most people said it was an FTP permissions issue, so I tried to go through that troubleshooting, but it did not help.
So I decided to image the laptop with a Win10 image even though it wouldn’t match the rest of the lab. When I tried that, I got an error that indicated that the target partition was too small. The image is a single disk resizeable image. I am trying to put it on a 250GB drive. The original drives it was created on were 500GB drives, but that’s all I had for a spare. It does image onto a “Same size” drive with no issues. -
I’d like to see you update to FOG 1.4.0RC9 to see if your issue has been resolved.
If the web ui has an image of 0 bytes. This almost sounds like the image was migrated to this server from another server. The image size is only recorded and written to the database when the image is captured on that fog server. Its not used during deployment it is only for informational purposes.
The FTP issue comes in at the end of image capture when the FOG server is moving the file on the hard drive. The FTP account is never used for deployment.
There was a bug in 1.3.5 under certain conditions the resize function didn’t work as expected. That bug was corrected in 1.4.0RC1. This may be an issue that has already been corrected.
So my recommendation still stands, upgrade to FOG 1.4.0RC9 and rerun your deployment. If there is still an issue we will start digging through the bits to get it going for you.
-
@george1421 I will try that. Thanks!
-
@george1421 I attempted the update to 1.4.0 RC9. The install ran ok until it got to the point where it was trying to copy binaries where needed. Then it failed. Any ideas?
-
@Tim-Reynolds Does your fog server have direct Internet access? The fog installer needs to download some files from the fog mothership to complete the install.
-
@george1421 It does have direct access.
-
@Tim-Reynolds from the linux console you can ping fogproject.org?
-
@george1421 I can’t ping, but it resolves it as 162.213.199.177. I can browse to it from Firefox.
-
Try now please.
-
@Tom-Elliott I’m still unable to. I can ping Google.
-
You don’t need to ping.
You can retry the installer.
-
@Tom-Elliott Copying binaries where needed still failed.
-
@Tom-Elliott It unzipped the binaries successfully, it just wouldn’t copy them.
-
That doesn’t make any sense. What do you mean “it unzipped but wouldn’t copy them?”
What’s output of
df -h? -
@Tom-Elliott Attached is a document with the results of df-h and the install.0_1494274173932_1.4.0-rc9
-
@Tim-Reynolds the attachment is a text file.
-
@Tim-Reynolds Did the file attachment shed some light on the problem?
-
@Tim-Reynolds Seems like you have enough free space on the disk. Tom is right, this does not make much sense. Do you see anything in the install error log?
-
I encountered another user having a similar problem with this yesterday. It happened to be the proxy/filter was causing the binary data not to be stored properly. The binaries file would download, but the data was not available and would cause a failure. @Tim-Reynolds Please see if you have a content filter that may be causing problems.
-
@Tom-Elliott I have a rule on the filter that ensures that the content filter is disabled on the Fog server’s IP address. Also, I have the firewall allow all traffic to the Fog server.
