Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 2 subscribers
  • Views 807 views
  • Users 0 members are here
Options
Suggested
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

Sill unable to upgrade to 7.400 - plz help

djsuck
Hi there,

I'm still unable to upgrade my Soaftware-ASG at my home.
Current firmware is still 7.3.0.6
The automatic firmware downloader is downloading.... oh boy... it's downloading.
I got about 15-17GB traffic due to that procedure... EVERY day [:O]
(Last month the update-process produced almost 480GB of traffic.)

When I try to do the update manually, the upload-process goes to ~99% ... then the transfer-rate slowly drops and in that little space, where the form used to be, where I select the update-file... i can see the login-screen of my ASG.
Its even possible to login... then I see the webinterface of the ASG in that tiny space.

Pretty strange, huh?
I tried increasing the admin timeout (to 3000 sec.) and I got 1GB of RAM in that machine... i think that should be fine.

Here's a little pice of my up2date logfile.
The automatic firmware download and the manual process should be in it.

I hope, i made myself clear (english is not my native language).
If you need any furthermore information to help me with this strange problem, plz let me know.

thx

2009:04:01-00:02:02 (none) auisys[10102]: Starting Up2Date Package Installer (Version 1.65)
2009:04:01-00:02:03 (none) auisys[10102]: Searching for available up2date packages for type 'auav'
2009:04:01-00:02:03 (none) auisys[10102]: id="371D" severity="info" sys="system" sub="up2date" name="No up2date packages available for installation" status="failed" action="install" package="auav"
2009:04:01-00:02:03 (none) auisys[10102]: Searching for available up2date packages for type 'clam'
2009:04:01-00:02:03 (none) auisys[10102]: id="371D" severity="info" sys="system" sub="up2date" name="No up2date packages available for installation" status="failed" action="install" package="clam"
2009:04:01-00:02:03 (none) auisys[10102]: Searching for available up2date packages for type 'ips'
2009:04:01-00:02:04 (none) auisys[10102]: id="371D" severity="info" sys="system" sub="up2date" name="No up2date packages available for installation" status="failed" action="install" package="ips"
2009:04:01-00:02:04 (none) auisys[10102]: Searching for available up2date packages for type 'man-sw'
2009:04:01-00:02:04 (none) auisys[10102]: id="371D" severity="info" sys="system" sub="up2date" name="No up2date packages available for installation" status="failed" action="install" package="man-sw"
2009:04:01-00:02:04 (none) auisys[10102]: Searching for available up2date packages for type 'ohelp'
2009:04:01-00:02:04 (none) auisys[10102]: id="371D" severity="info" sys="system" sub="up2date" name="No up2date packages available for installation" status="failed" action="install" package="ohelp"
2009:04:01-00:02:04 (none) auisys[10102]: id="3716" severity="info" sys="system" sub="up2date" name="Up2date Package Installer finished, exiting"

AND:
2009:04:01-00:33:01 (none) audld[11977]: http://213.198.93.249:80/asg/v7/sys/u2d-sys-7.400.tgz.gpg Checksum mismatch with downloaded file
2009:04:01-00:33:01 (none) audld[11977]: 
2009:04:01-00:33:01 (none) audld[11977]:  1. Modules::Getupdates::sync_local:1059() audld.pl
2009:04:01-00:33:01 (none) audld[11977]:  2. main:[:D]ownload:651() audld.pl
2009:04:01-00:33:01 (none) audld[11977]:  3. main::run:377() audld.pl
2009:04:01-00:33:01 (none) audld[11977]:  4. main::top-level:33() audld.pl
2009:04:01-00:33:07 (none) audld[11977]: |=========================================================================
2009:04:01-00:33:07 (none) audld[11977]: http://213.198.93.249:80/asg/v7/sys/u2d-sys-7.400.tgz.gpg Protocol Error code=416
2009:04:01-00:33:07 (none) audld[11977]: 
2009:04:01-00:33:07 (none) audld[11977]:  1. Modules::Getupdates::sync_local:1042() audld.pl
2009:04:01-00:33:07 (none) audld[11977]:  2. main:[:D]ownload:651() audld.pl
2009:04:01-00:33:07 (none) audld[11977]:  3. main::run:377() audld.pl
2009:04:01-00:33:07 (none) audld[11977]:  4. main::top-level:33() audld.pl
2009:04:01-00:33:13 (none) audld[11977]: |=========================================================================
2009:04:01-00:33:13 (none) audld[11977]: http://213.144.15.5:80/asg/v7/sys/u2d-sys-7.400.tgz.gpg Protocol Error code=416


This thread was automatically locked due to age.
Parents
  • 0
    If you do mind losing the logs, try manually downloading the up2dates via FTP and manually upload them to the firewall and then install them.
  • 0 in reply to Simon Shaw
    I've seen this issue come up once on one of our own test backbone machines. The problem is that the downloader completes the download (it says '100% downloaded, and the byte sum is correct) but afterwards fails to verify the md5sum of the package (hence the "Checksum mismatch" message. Since the downloader assumes that a package which is announced by an up2date server to have size X and md5sum Z really DOES have size X and md5sum Z, it decides that the offered by this server is not complete and tries to resume at another server, which responds with the HTTP Error Code 416 (bad request range - essentially the client requests a range which can't be delivered because the file is already downloaded completely).

    Basically it comes down to this: the server offers the up2date package with a given size and md5sum. When the file is downloaded completely, the md5sum of the local package does not match the md5sum of the offered package. The files on the up2date servers are OK though, as are the md5sums that are offered. This leads to the conclusion that during the download the download got corrupted, how this happened is unknown.
    I've talked this through with a colleague at that time when I've seen it here. I suggested it might be a harddisk failure which is starting to show up, but we don't know anything for sure. My colleague decided to install a fresh 7.401 ISO image on the machine and since then it is working without any hickups.

    Before you do anything rash though, can you please provide information about your up2date history? Please do an 'ls -al /tmp/.u2d*' and post the output here.

    Thank you,
     andreas

    Edit: Bypassing the up2date downloader as suggested by Simon might work too, but it might happen again with the next up2date package that needs to be downloaded. It is also likely that this also affects pattern up2dates, if you decide to go this way please make sure to check if pattern up2dates work.
Reply
  • 0 in reply to Simon Shaw
    I've seen this issue come up once on one of our own test backbone machines. The problem is that the downloader completes the download (it says '100% downloaded, and the byte sum is correct) but afterwards fails to verify the md5sum of the package (hence the "Checksum mismatch" message. Since the downloader assumes that a package which is announced by an up2date server to have size X and md5sum Z really DOES have size X and md5sum Z, it decides that the offered by this server is not complete and tries to resume at another server, which responds with the HTTP Error Code 416 (bad request range - essentially the client requests a range which can't be delivered because the file is already downloaded completely).

    Basically it comes down to this: the server offers the up2date package with a given size and md5sum. When the file is downloaded completely, the md5sum of the local package does not match the md5sum of the offered package. The files on the up2date servers are OK though, as are the md5sums that are offered. This leads to the conclusion that during the download the download got corrupted, how this happened is unknown.
    I've talked this through with a colleague at that time when I've seen it here. I suggested it might be a harddisk failure which is starting to show up, but we don't know anything for sure. My colleague decided to install a fresh 7.401 ISO image on the machine and since then it is working without any hickups.

    Before you do anything rash though, can you please provide information about your up2date history? Please do an 'ls -al /tmp/.u2d*' and post the output here.

    Thank you,
     andreas

    Edit: Bypassing the up2date downloader as suggested by Simon might work too, but it might happen again with the next up2date package that needs to be downloaded. It is also likely that this also affects pattern up2dates, if you decide to go this way please make sure to check if pattern up2dates work.
Children
No Data
Cookie Information Banner