This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Up2Date prefetch failed

Hi ...im running asg 7.104 and get this error all the time...something i can do to get this right?
I saw that there was some linux commands i could run...but im not very good at linux.

newbie

Peter


This thread was automatically locked due to age.
  • hi all,
    as in the title, this is the hardest up2date as I remember(ASL1.***x),
    be quite and patient and try to do like me ;
    download the package from the FTP site and try to reinstall it in manual mode and not in 
    automatic.
    I try in this way twice and after a very long reboot(5 minutes) ASG starts regulary in a normal way.
    I hope this should be helpfull.
  • The miracle of all my astaro's updating on 5/19 seems to be due to the proxy crashing on my 425. I found an email sent from the 425 on 5/19 stating "http proxy not running - restarted" I've placed the up2date IP's in the transparent mode skiplist, along with the Interal IP of the remote astaros, but it still appears to be blocked. I seems simple fix now that I know it's the http proxy on the 425, but since the transparent mode skiplist doesn't seem to allow the traffic, I'm at a loss on what to configure to allow the up2date traffic to bypass the http proxy.
  • This should be the final post on this one for me. The transparent mode skiplist does work, but for some reason it only works if I have a static route to one of the up2date servers out the Default Gateway for authentication on port 443. The update will download over the tunnel via port 80. So it's actually working now. One interesting note is the static route needs to be toggled off/on after a reset on the unit for some reason, or the route isn't entered into the routing table properly. Thanks for all the input everyone.
  • After upgrading from 7.104 to 7.2, it no longer works. Did the up2date servers change? I dont' see the IP's in the up2date.log anymore. Here was my list for 7.104:


    213.144.15.5 -I set static route to DG on Eth1(primary interface)
    213.198.93.249 - added to http proxy skiplist
    128.121.10.115 - added to http proxy skiplist
    218.213.238.229 - added to http proxy skiplist
    128.242.114.243 - added to http proxy skiplist
    69.10.147.76 - added to http proxy skiplist
  • We're still using the same servers as before, running with the same configuration, on the same IP addresses:

    [Server_1]
    Host = v7up2date1.astaro.com
    Ip   = 213.198.93.249
    [Server_2]
    Host = v7up2date2.astaro.com
    Ip   = 69.10.147.76
    [Server_3]
    Host = v7up2date3.astaro.com
    Ip   = 213.144.15.5
    [Server_4]
    Host = v7up2date4.astaro.com
    Ip   = 128.242.114.243
    [Server_5]
    Host = v7up2date5.astaro.com
    Ip   = 128.121.10.115
    [Server_6]
    Host = v7up2date6.astaro.com
    Ip   = 218.213.238.229

    The only change that has been done in the last weeks is that we took v7up2date1 from the regular server list and used it as a Beta-Up2date Server during the v7.200 beta phase, but in the meantime it has been added again.
    I am puzzled; I know you've checked and re-checked everything, but I also know it works flawless for many thousands of machines out there, which leads me to think it is caused by a peculiarity of your network, or the way you connect to the internet. Can you maybe do some routing traces using a tcp traceroute, or try to use a dial-up internet access just for checking if it works this way?

    Cheers,
     andreas
  • Thanks Andreas. It's definitely due to our configuration. We have a 425(Hub) with 20 other Astaro's(Spokes) All traffic on remotes are sent through the tunnel to the 425. I was working with a static route on the remotes, now after 7.2 it stopped working again. That info is helpful. Does the up2date process query DNS for those IP addresses?
  • Yes, there is a process which is running every couple of hours to adjust the actual server list (/etc/up2date/servers.sorted) to the network situation, to reflect changes like ASG was shipped/moved somewhere, routing issues, we adding a new update server, ...
    This process tries to resolve the names, only if this does not work the fallback IP address is used. It then checks the servers responsibility by running netselect on them, which is using a mixture of ICMP and UDP packets, in order to set the fastest server for this ASG to the top of the sorted server list.
    The up2date downloader then walks through this list, starting with the server on the top of the list, but also trying the others if the authentication/download fails for some reason.

    I hope that helps,
    Cheers,
     andreas