Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 18 replies
  • Subscribers 2 subscribers
  • Views 8182 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

HELP! ASG220 update to V.7 problem

COACT
Hello,

I'm sitting here on a Saturday morning, waiting for the update to my ASG220 to complete.

The box was at ver 6.311 and I initiated the v.7 firmware update thru the up2date web interface. It downloaded the firmware properly, verified the signature, and claimed to be installing the update.

It said it would take 30 minutes. It has now been 2 hours and the display on the ASG220 still says *** Astaro Security Gateway ***. During the upgrade it warned about reseting or rebooting the box as it might render it useless, but I am at a loss as to what to do or how long to wait.

Any suggestions? I had to rig up a special network connection just to get to this forum since the upgrade has disabled the network. 

Lou


This thread was automatically locked due to age.
Parents
  • 0
    Lou, what can you see in /var/upgrade/upgrade.log ?

    You might want to monitor that file to decide what's going on during the firmware upgrade.

    Thing is, if the upgrade fails it won't tell you by itself. It'll just exit and leave you wondering to restart or not.

    Arthur
  • 0 in reply to Arthur.Bommele
    Lou, what can you see in /var/upgrade/upgrade.log ?


    Arthur, 

    I have not looked at the log file you mentioned but using the ASG220 log file query process, here is what was happening in the system log right before-during-and right after ht upgrade attempt. The time between 09:12 and 12:09 is roughly the time period where the box sat with the "Astaro Security Gateway" display and appeared dead to the world. Oddly, a query of the up2date log revealed not a single entry during the time period.

    2007:07:28-08:57:58 (none) daemon-watcher[3069]: Watching selfmonng.pl - running fine
    2007:07:28-09:00:00 (none) /USR/SBIN/CRON[15623]: (root) CMD ( /usr/local/bin/reportcontrol.sh)
    2007:07:28-09:05:00 (none) /USR/SBIN/CRON[17490]: (root) CMD ( /usr/local/bin/reportcontrol.sh)
    2007:07:28-09:10:00 (none) /USR/SBIN/CRON[19594]: (root) CMD ( /usr/local/bin/reportcontrol.sh)
    2007:07:28-09:12:54 (none) init: Switching to runlevel: 1
    2007:07:28-09:13:21 (none) syslog-ng[1324]: Changing permissions on special file /dev/null.syslog
    2007:07:28-09:13:23 (none) ulogd[2260]: sigterm received, exiting
    2007:07:28-09:13:23 (none) syslog-ng[1324]: syslog-ng version 1.6.7 going down
    2007:07:28-12:09:12 (none) syslog-ng[1324]: syslog-ng version 1.6.7 starting
    2007:07:28-12:09:17 (none) syslog-ng[1324]: Changing permissions on special file /dev/null.syslog
    2007:07:28-12:09:17 (none) /usr/sbin/cron[1786]: (CRON) STARTUP (fork ok)
    2007:07:28-12:09:20 (none) init: Switching to runlevel: 3
    2007:07:28-12:09:21 (none) ulogd[2259]: ulogd Version 1.23 starting
    2007:07:28-12:09:21 (none) ulogd[2261]: initialization finished, entering main loop
    2007:07:28-12:09:43 (none) daemon-watcher[3069]: This is daemon-watcher v1.1 2004/02/11 11:56:23 ghansen starting...
    2007:07:28-12:09:43 (none) daemon-watcher[3069]: Watching selfmonng.pl...
    2007:07:28-12:09:54 (none) syslog-ng[1324]: SIGHUP received, restarting syslog-ng
    2007:07:28-12:09:56 (none) syslog-ng[1324]: new configuration initialized
    2007:07:28-12:10:00 (none) /usr/sbin/cron[1786]: (*system*) RELOAD (/etc/crontab)
    2007:07:28-12:10:01 (none) /USR/SBIN/CRON[3939]: (root) CMD ( /usr/local/bin/reportcontrol.sh)
    2007:07:28-12:10:05 (none) snmpd[3933]: error finding row index in _ifXTable_container_row_restore
    2007:07:28-12:10:05 (none) snmpd[3933]: error finding row index in _ifXTable_container_row_restore
    2007:07:28-12:10:05 (none) snmpd[3933]: error finding row index in _ifXTable_container_row_restore
    2007:07:28-12:10:05 (none) snmpd[3933]: error finding row index in _ifXTable_container_row_restore
    2007:07:28-12:10:05 (none) snmpd[3933]: NET-SNMP version 5.3.0.1
    2007:07:28-12:10:16 (none) syslog-ng[1324]: Changing permissions on special file /dev/null.syslog
    2007:07:28-12:10:17 (none) snmpd[3933]: Received TERM or STOP signal... shutting down...
    2007:07:28-12:10:24 (none) snmpd[4255]: NET-SNMP version 5.3.0.1
    2007:07:28-12:10:29 (none) syslog-ng[1324]: SIGHUP received, restarting syslog-ng
    2007:07:28-12:10:31 (none) syslog-ng[1324]: new configuration initialized
    2007:07:28-12:10:51 (none) ez-ipupdate: Ez-IPupdate stopped.
    2007:07:28-12:10:52 (none) syslog-ng[1324]: SIGHUP received, restarting syslog-ng
    2007:07:28-12:10:56 (none) syslog-ng[1324]: new configuration initialized
    2007:07:28-12:11:00 (none) /usr/sbin/cron[1786]: (*system*) RELOAD (/etc/crontab)
    2007:07:28-12:11:31 (none) system[5966]: System was restarted
    2007:07:28-12:11:56 (none) syslog-ng[1324]: SIGHUP received, restarting syslog-ng
    2007:07:28-12:11:58 (none) syslog-ng[1324]: new configuration initialized
    2007:07:28-12:12:00 (none) /usr/sbin/cron[1786]: (*system*) RELOAD (/etc/crontab)
    2007:07:28-12:12:05 (none) ez-ipupdate: Ez-IPupdate stopped.
    2007:07:28-12:13:00 (none) /usr/sbin/cron[1786]: (*system*) RELOAD (/etc/crontab)
    2007:07:28-12:15:00 (none) /usr/sbin/cron[1786]: (*system*) RELOAD (/etc/crontab)
    2007:07:28-12:15:00 (none) /USR/SBIN/CRON[6837]: (root) CMD ( /usr/local/bin/reportcontrol.sh)
    2007:07:28-12:20:00 (none) /USR/SBIN/CRON[7041]: (root) CMD ( /usr/local/bin/reportcontrol.sh)
    2007:07:28-12:25:00 (none) /USR/SBIN/CRON[7237]: (root) CMD ( /usr/local/bin/reportcontrol.sh)
    2007:07:28-12:29:16 (none) daemon-watcher[3069]: Watching selfmonng.pl - running fine
    2007:07:28-12:30:00 (none) /USR/SBIN/CRON[7465]: (root) CMD ( /usr/local/bin/reportcontrol.sh)
    2007:07:28-12:30:00 (none) /USR/SBIN/CRON[7467]: (root) CMD (/usr/local/bin/content_manager.pl global_nuke cleanup)
    2007:07:28-12:35:00 (none) /USR/SBIN/CRON[7674]: (root) CMD ( /usr/local/bin/reportcontrol.sh)
    2007:07:28-12:40:00 (none) /USR/SBIN/CRON[7914]: (root) CMD ( /usr/local/bin/reportcontrol.sh)
    2007:07:28-12:45:00 (none) /usr/sbin/cron[1786]: (*system*) RELOAD (/etc/crontab)
    2007:07:28-12:45:00 (none) /USR/SBIN/CRON[8251]: (root) CMD ( /usr/local/bin/reportcontrol.sh)
    2007:07:28-12:49:12 (none) daemon-watcher[3069]: Watching selfmonng.pl - running fine

    Lou
  • 0 in reply to COACT
    Lou,

    Thanks, but /var/upgrade/upgrade.log is really the file that (still) contains what did or did not happen during the upgrade.

    Gain console access (SSH) and reveal the content of your upgrade.log file.

    Arthur
  • 0 in reply to Arthur.Bommele
    Gain console access (SSH) and reveal the content of your upgrade.log file.Arthur


    Here it is:

    =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2007.07.31 15:18:03 =~=~=~=~=~=~=~=~=~=~=~=
    /var/upgrade > more upgrade.log
    Sat Jul 28 07:49:43 EDT 2007 :: Upgrade initialization started
    Sat Jul 28 07:49:43 EDT 2007  Creating /var/storage/upgrade
    Sat Jul 28 07:49:43 EDT 2007 :: Checking for required utilities
    Sat Jul 28 07:49:43 EDT 2007  parted is installed
    Sat Jul 28 07:49:43 EDT 2007 :: Checking space on /var/storage
    Sat Jul 28 07:49:43 EDT 2007  Enough free space on storage partition (12109 MiB)
    Sat Jul 28 07:49:43 EDT 2007 :: Searching for upgrade servers
    Sat Jul 28 07:50:32 EDT 2007  Using ftp.astaro.de
    Sat Jul 28 07:50:36 EDT 2007 :: Making backup
    Sat Jul 28 07:50:36 EDT 2007  /etc/modules.conf
    Sat Jul 28 07:50:36 EDT 2007  /etc/modules
    Sat Jul 28 07:50:36 EDT 2007  /etc/sysconfig/kernel
    Sat Jul 28 07:50:36 EDT 2007  /etc/asg
    Sat Jul 28 07:50:36 EDT 2007  /etc/securetty
    Sat Jul 28 07:50:36 EDT 2007  /etc/serial.conf
    Sat Jul 28 07:50:36 EDT 2007  /etc/usb.conf
    Sat Jul 28 07:50:36 EDT 2007  /etc/guid
    Sat Jul 28 07:50:36 EDT 2007  Creating V6 backup file
    Sat Jul 28 07:50:36 EDT 2007 Turning off backup encryption
    Sat Jul 28 07:50:46 EDT 2007 Turning on backup encryption again
    Sat Jul 28 07:52:20 EDT 2007 :: up_fetch started
    Sat Jul 28 07:52:20 EDT 2007 :: Setting iptables rule
    Sat Jul 28 07:52:20 EDT 2007 :: Fetching ftp://ftp.astaro.de/pub/Astaro_Security
    _Linux/Migration_6.3-7.0/asg-7.005.bin
    Sat Jul 28 09:11:43 EDT 2007 :: Fetching ftp://ftp.astaro.de/pub/Astaro_Security
    _Linux/Migration_6.3-7.0/asg-7.005.bin.md5
    Sat Jul 28 09:11:50 EDT 2007 :: Checking MD5 sum
    Sat Jul 28 09:12:30 EDT 2007  MD5 checksum OK
    Sat Jul 28 09:12:34 EDT 2007 :: Resetting iptables rule
    Sat Jul 28 09:12:53 EDT 2007 :: Upgrade started
    Sat Jul 28 09:12:53 EDT 2007 :: Check version
    Sat Jul 28 09:12:53 EDT 2007  Installed version is 6.311
    Sat Jul 28 09:12:53 EDT 2007 :: Preparing runlevel 1
    Sat Jul 28 09:12:53 EDT 2007 :: Switching to runlevel 1
    Sat Jul 28 09:13:24 EDT 2007 :: Upgrade Preparation started
    Sat Jul 28 09:13:24 EDT 2007 :: Inspecting current system
    Sat Jul 28 09:13:24 EDT 2007  ASG root disk is /dev/hdc
    Sat Jul 28 09:13:27 EDT 2007  Found 'default' kernel
    Sat Jul 28 09:13:27 EDT 2007  Making found data persistent
    Sat Jul 28 09:13:27 EDT 2007 :: Creating Provisional Upgrade Partition
    Sat Jul 28 09:13:27 EDT 2007  Turning swap off
    Sat Jul 28 09:13:27 EDT 2007  Creating filesystem on /dev/hdc2
    /dev/hdc2 is mounted; will not make a filesystem here!
    Sat Jul 28 09:13:27 EDT 2007 mke2fs failed
    Sat Jul 28 09:13:27 EDT 2007 :: Restoring swap partition
    Sat Jul 28 09:13:27 EDT 2007  Done




    Lou
  • 0 in reply to COACT
    Thanks, it's the exact same issue as I have:
    "/dev/hdc2 is mounted, will not make a filesystem here!"

    The answer I got from Astaro is that the upgrade process uses the swap partition to upgrade the firewall so please check that your swap partition is empty.

    Haven't had time yet to look into it further. But swap itself is turned off during the upgrade and the swap partition /dev/hdc2 seems to have used half of available blocks.

    Will let you know what I find out.

    Arthur
  • 0 in reply to Arthur.Bommele
    The answer I got from Astaro is that the upgrade process uses the swap partition to upgrade the firewall so please check that your swap partition is empty.


    Since I'm using THEIR automated up2date process on THEIR hardware box, is it too much for a normal user like myself to actually expect THEM to take care of this as part of the upgrade and not pass it off to the user?? [:D] 

    Ok, so I'm a tad bit sarcastic today....
  • 0 in reply to COACT
    Looks like /var/upgrade/up_prepare does the following:

    swapoff -a
    mke2fs -m0 -q -j /dev/hdc2

    The first command fails because swapoff cannot allocate memory.
    So the second command fails because /dev/hdc2 is still in use for swap area
    (/dev/hdc2 is mounted; will not make a filesystem here!)

    Perhaps 'swapoff -a' should not be used but rather 'swapoff /dev/hdc2' to check for a possible error code and if so free up the swap with commands like '/var/mdw/scripts/snort stop' or something until 'swapoff /dev/hdc2' is succesfull. Then the mke2fs command should be succesfull and the upgrade can continue.

    But that's for another time.

    Arthur
  • 0 in reply to Arthur.Bommele
    Hey Lou, 

    die you contect THEM, so THEIR support can take a look at it?
    [:)]

    regards
    Gert
  • 0 in reply to Gert Hansen
    did you contact THEM, so THEIR support can take a look at it?
    [:)]


    Yep! They suggested that I manually download the SAI iso file and use the USB cdrom method - which I will when I am able to schedule the downtime for maintenance and try it again.

    Guess they don't have much faith in their automated method either, to which I say - why make it an available option if it's not rock-solid?

    Oh, well. Onto the next crisis. [8-)] 

    Lou
  • 0 in reply to COACT
    [:)]

    Yeah, I've been upgrading exclusively with the USB CD-ROM method... that way I'm absolutely sure of a good conversion (at least the best odds of getting it right, anyhow) ...  I wouldn't recommend any other way right now.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0 in reply to BrucekConvergent
    auto-upgrade from 6.311 to 7.005 completed
    thanks to tips from Contec iSC support

    procedure:
    - disable HTTP Proxy, SMTP Proxy and Intrusion Detection
    - restart ASG220
    - use the console command 'free' to check if swap area is small enough for 'swapoff -a' to work
    - start auto upgrade (step 1, step 2, step 3)
    - login to the new WebAdmin

    This starts with "Basic System Setup"?
    If you "Restore existing backup file" it'll say "Backup corrupt".
    So "Cancel Wizard". Don't bother with "Management, Backup/Restore, V6 backup import..." either because that's already done.

    You'll need to manually (re)configure HTTP Proxy, SMTP Proxy, Shell Access, Shell User passwords, Password Complexity, NTP, VPN, Date and Time, Intrusion Protection and a few other things I forgot.

    After that installed the update 7.006. No problems so far.

    At least in theory the above should work remotely. Provided you enable remote access for SSH and WebAdmin correctly.
    Anyone out there that can confirm?
Reply
  • 0 in reply to BrucekConvergent
    auto-upgrade from 6.311 to 7.005 completed
    thanks to tips from Contec iSC support

    procedure:
    - disable HTTP Proxy, SMTP Proxy and Intrusion Detection
    - restart ASG220
    - use the console command 'free' to check if swap area is small enough for 'swapoff -a' to work
    - start auto upgrade (step 1, step 2, step 3)
    - login to the new WebAdmin

    This starts with "Basic System Setup"?
    If you "Restore existing backup file" it'll say "Backup corrupt".
    So "Cancel Wizard". Don't bother with "Management, Backup/Restore, V6 backup import..." either because that's already done.

    You'll need to manually (re)configure HTTP Proxy, SMTP Proxy, Shell Access, Shell User passwords, Password Complexity, NTP, VPN, Date and Time, Intrusion Protection and a few other things I forgot.

    After that installed the update 7.006. No problems so far.

    At least in theory the above should work remotely. Provided you enable remote access for SSH and WebAdmin correctly.
    Anyone out there that can confirm?
Children
No Data
Cookie Information Banner