cluster image package get failed from CDOT 9.1 to 9.2RC1

[Lei]

Hi,

I have been experienced  cluster image package get failed from CDOT 9.1 to 9.2RC1

Package download started.......................................... .................................................................. Package download failed.
Error: command failed: Package download failed due to a timeout.

somehow it failed and stopped downloading in backgroud, which not like 8.3RC1, it failed but still download in the backupgroup and after the files download completed you could still use
cluster image package get packagename and get it validate after this which i upgrade from 8.3RC1 to 9.1.

but in 9.1 no such options. cluster image package get command only works for URL.

Also somehow if you try system node image get -node nodename -package from the same URL, it has percentage showing.. and eventuyally it succesfful, from i can tell
- cluster image package get URL and system node image get -node nodename -package URL used the differnent time-out value and maybe different mechanism

This is from differnt domain and legacy network, 780MB+ not small.  so i am wondering is there any way to troubleshoot or change the  cluster image package get  default time out vaule ?

Cheers

Lei 

[Lei]

Also quite silly , this command cluster image package get URL should detect the existing packet first before go to the external web-server URL I basically downloaded all the packets from two nodes, but due this command failed, i have to to distributive update why there is no way to validate the packets from the individual nodes ? doesn't make sense to me.

[robinpeter]

I can confirm it works for me.. 

::*> cluster image package get -url http://10.90.61.104/netapp/91P5_q_image.tgz
Package download completed.
Package processing completed.   

I always make sure I have a *LOCAL* webserver sharing the ontap image via HTTP.

Creating the local webserver takes just two of three clicks..

so why not use the local server rather than depends on a remote server and have a dependency on network latency.

Once you download and verify the MD5SUM of Ontap image..  you can use something like hfs http server 

to create a simple http server.. (http://www.rejetto.com/hfs/?f=dl)

Generally I use the "system image get -node * -package http://ipaddress/image.tgz" command to download to each node.

[Lei]

Thanks robinpeter ,

Yes, in my other cluster it works fine.  but like i said, there is no way i could find out the same webseve in this subnet. since we have very complicated environment. 

this legacy subnet all IP address have been allocated, and the security reason not allow me to get another websever.

the reason i am asking

"system image get -node * -package http://ipaddress/image.tgz"  is working  but not cluster image package get -url http://ipaddress/image.tgz

the second one will get fail due to timeout, what i am trying to say , there must be something different between these two functions.    without the cluster image package get working.. i am not able to valiate the new code.  has to use the old way to upgrade node by node. it's painful.

anyway, thanks for your input, i will raise NetApp case for this one.

Cheers

Lei

[mohammedimrankhan]

Hi,  Did you manage to find a solution to this?

[andris]

Is the download taking longer than 45 minutes?

See Bug 1048640

You'll need tech support assistance for the workaround.

[Nagar]

Hey Robin,

Did you get any solution ?

Regards

Abhishek

[AlexDawson]

Hi Abhi,

We have options to workaround this issue - but putting the webserver somewhere where a reasonable speed can be acheived for downloads is the best option. If there are spare ports, configuring a temporary IP on the node-mgmt SVM and plugging a laptop in might be a good one.

Otherwise, please contact support, and state that you believe you are hitting BURT 1048640 and they will be able to help you with a workaround to pull the file onto it with SCP. 

[aborzenkov]

This specific bug is stated to be fixed in both 9.1 and 9.2RC1. May be there are other conditions that trigger this problem?

[andris]

The "fix" was to double the timoue period from 45 minutes to 90 minutes. However, if there are fundamental speed or network quality issues present when trying to download the image, you could still run into issues.