Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
9 REPLIES 9
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, Did you manage to find a solution to this?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is the download taking longer than 45 minutes?
See Bug 1048640
You'll need tech support assistance for the workaround.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hey Robin,
Did you get any solution ?
Regards
Abhishek
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.