Jump to content
Vodia PBX forum
Pablo

Upgrading to v5 from v4.5 on SoHo

Recommended Posts

I'm running version 4.5.0.1090 Epsilon Geminids (snom ONE mini) on a SoHo. I followed the upgrade instructions on the snom ONE wiki and, under the System tab, copied & pasted http://snomone.com/downloads/snomONE/version-5.0.2.xml in the Software Update field. I clicked Save and checked the log, and read the following:

[1] 2012/11/17 11:57:45: Performing software upgrade based on http://snomone.com/downloads/snomONE/version-5.0.2.xml

[3] 2012/11/17 11:57:45: Software update: Removing file pbxctrl-old

[1] 2012/11/17 11:57:45: Cannot remove file pbxctrl-old

[3] 2012/11/17 11:57:45: Software update: Sending request for file http://snomone.com/downloads/snomONE/audio/audio_moh/bi_ced.wav

[5] 2012/11/17 11:57:46: The type is not executable for file audio_moh/bi_ced.wav

[1] 2012/11/17 11:57:46: Software update finished. If there were no errors, changes will be completed after the snom ONE restart

I then rebooted the PBX (but have not tried rebooting the SoHo, yet) and found that the upgrade failed, when I checked under the Status tab.

Is this entry, the culprit?: [5] The type is not executable for file audio_moh/bi_ced.wav

FYI I created symbolic links to the audio folders under the snom ONE working directory, e.g. audio_moh -> /mnt/usb/audio_moh

Thanks!

Share this post


Link to post
Share on other sites

It could be that the SoHo is using a different name than "pbxctrl" for the executable. If you can log in on SSH, you can check the file in /etc/init.d/snomone what name the executable has and change it accordingly to "pbxctrl".

 

We included the bi_ced.wav file in the upgrade to make sure that everyone has the file in the audio_moh directory. The log/error is misleading (needs to be taken out from the code); upgrades may include non-executable files. For example, it should be possible to install languages by using the software update mechanism.

Share this post


Link to post
Share on other sites

It could be that the SoHo is using a different name than "pbxctrl" for the executable. If you can log in on SSH, you can check the file in /etc/init.d/snomone what name the executable has and change it accordingly to "pbxctrl".

 

We included the bi_ced.wav file in the upgrade to make sure that everyone has the file in the audio_moh directory. The log/error is misleading (needs to be taken out from the code); upgrades may include non-executable files. For example, it should be possible to install languages by using the software update mechanism.

 

I think the name is correct. But, just in case, here's a copy of /etc/init.d/snomONE

 

 

#! /bin/sh

### BEGIN INIT INFO

# Provides: snomONE

# Required-Start: $remote_fs

# Required-Stop: $remote_fs

# Default-Start: 2 3 4 5

# Default-Stop: 0 1 6

# Short-Description: snomONE

# Description: snomONE IP PBX

### END INIT INFO

#

# Author: Federico Musto <federico@snom.us.com>

#

PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/snomONE

DESC="snomONE IP PBX"

NAME=pbxctrl

DAEMON=/usr/local/snomONE/$NAME

DAEMON_ARGS="--dir /usr/local/snomONE/ --config /usr/local/snomONE/pbx.xml"

PIDFILE=/var/run/$NAME.pid

SCRIPTNAME=/etc/init.d/$NAME

 

# Exit if the package is not installed

[ -x "$DAEMON" ] || exit 0

 

# Read configuration variable file if it is present

[ -r /etc/default/$NAME ] && . /etc/default/$NAME

 

# Load the VERBOSE setting and other rcS variables

. /lib/init/vars.sh

 

# Overwrite VERBOSE value

VERBOSE=yes

# Define LSB log_* functions.

# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.

. /lib/lsb/init-functions

 

#

# Function that starts the daemon/service

#

do_start()

{

# Return

# 0 if daemon has been started

# 1 if daemon was already running

# 2 if daemon could not be started

start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \

|| return 1

start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \

$DAEMON_ARGS \

|| return 2

# Add code here, if necessary, that waits for the process to be ready

# to handle requests from services started subsequently which depend

# on this one. As a last resort, sleep for some time.

}

 

#

# Function that stops the daemon/service

#

do_stop()

{

# Return

# 0 if daemon has been stopped

# 1 if daemon was already stopped

# 2 if daemon could not be stopped

# other if a failure occurred

#start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME

#RETVAL="$?"

#[ "$RETVAL" = 2 ] && return 2

# Wait for children to finish too if this is a daemon that forks

# and if the daemon is only ever run from this initscript.

# If the above conditions are not satisfied then add some other code

# that waits for the process to drop all resources that could be

# needed by services started subsequently. A last resort is to

# sleep for some time.

start-stop-daemon --stop --quiet --oknodo --retry=KILL/5 --exec $DAEMON

RETVAL="$?"

 

[ "$RETVAL" = 2 ] && return 2

# Many daemons don't delete their pidfiles when they exit.

rm -f $PIDFILE

return "$RETVAL"

}

 

#

# Function that sends a SIGHUP to the daemon/service

#

do_reload() {

#

# If the daemon can reload its configuration without

# restarting (for example, when it is sent a SIGHUP),

# then implement that here.

#

start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name $NAME

return 0

}

 

case "$1" in

start)

[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"

do_start

case "$?" in

0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;

2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;

esac

;;

stop)

[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME - Please wait from a few seconds to several minutes"

do_stop

case "$?" in

0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;

2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;

esac

;;

restart)

#

# If the "reload" option is implemented then remove the

# 'force-reload' alias

#

log_daemon_msg "Restarting $DESC" "$NAME"

do_stop

case "$?" in

0|1)

do_start

case "$?" in

0) log_end_msg 0 ;;

1) log_end_msg 1 ;; # Old process is still running

*) log_end_msg 1 ;; # Failed to start

esac

;;

*)

# Failed to stop

log_end_msg 1

;;

esac

;;

*)

echo "Usage: $SCRIPTNAME {start|stop|restart}" >&2

exit 3

;;

esac

 

:

 

Is there anything in here that needs to be changed? Thanks.

Share this post


Link to post
Share on other sites

Indeed, it looks okay. If you cd into the /usr/local/snomONE directory, try calling ./pbxctrl --version to see what version you are running. While you are there, you can also just wget the executable and skip the upgrade from the HTTP interface.

Share this post


Link to post
Share on other sites

Indeed, it looks okay. If you cd into the /usr/local/snomONE directory, try calling ./pbxctrl --version to see what version you are running. While you are there, you can also just wget the executable and skip the upgrade from the HTTP interface.

 

 

I ran the Linux command and the result was: Version: 4.5.0.1090 Epsilon Geminids

 

I'll try wget, next. When I click on the link http://snomone.com/downloads/snomONE/version-5.0.2.xml to get the URL for the executable, I don't see a line for a SoHo / Sheeva Update, like there was for 4.5.0.1090. Should I download this version: http://snomone.com/downloads/snomONE/debian32/pbxctrl-debian32-5.0.2 ?

Share this post


Link to post
Share on other sites

The version-5.0.2.xml did not contain the link yet... Please try again, the file should not have the link.

 

From the shell, you can just use "wget http://snomone.com/downloads/snomONE/mini/pbxctrl-mini-5.0.2".

 

No luck! Here are the steps I took: from root, entered cd /usr/local/snomONE; from there, I ran a wget to the URL for the mini you provided; I then executed the following command chmod a+x pbxctrl-mini-5.0.2; then mv pbxctrl pbxctrl-old; then mv pbxctrl-mini-5.0.2 pbxctrl

I then restarted snomONE (i.e. not the server). Now, my remote phone does not register and I can not access the PBX web login page, neither remotely or on the LAN. The weird part is, however, that I am able to access the admin section of the SoHo via x.x.x.x:81. I'm also still able to SSH. While in the working directory, I ran ./pbxctrl --version and the system's response was: ./pbxctrl: /usr/lib/libstdc++.so.6: version `CXXABI_ARM_1.3.3' not found (required by ./pbxctrl)

 

 

Any suggestions? (Yes, I did backup b/f trying this.)

Share this post


Link to post
Share on other sites
I then restarted snomONE (i.e. not the server). Now, my remote phone does not register and I can not access the PBX web login page, neither remotely or on the LAN. The weird part is, however, that I am able to access the admin section of the SoHo via x.x.x.x:81. I'm also still able to SSH. While in the working directory, I ran ./pbxctrl --version and the system's response was: ./pbxctrl: /usr/lib/libstdc++.so.6: version `CXXABI_ARM_1.3.3' not found (required by ./pbxctrl)

 

I have the exact same issue with the snom SoHo.

Share this post


Link to post
Share on other sites

Oh, this is probably because the snom ONE Soho was using its own Linux distribution. We changed that to a standard Debian distribution on the mini.

 

 


root@snomonemini:~$ ls -al /usr/lib/libstdc++.so.6.0.13
-rw-r--r-- 1 root root 874176 Nov 15  2010 /usr/lib/libstdc++.so.6.0.13

 

I searched a little bit in the Internet; seems that problem is a common problem. If you have a mini, maybe you can just copy the lib files over to the Soho. If it all does not help it seems we have to compile the executable again on the old Soho platform.

Share this post


Link to post
Share on other sites

Oh, this is probably because the snom ONE Soho was using its own Linux distribution. We changed that to a standard Debian distribution on the mini.

 

 


root@snomonemini:~$ ls -al /usr/lib/libstdc++.so.6.0.13
-rw-r--r-- 1 root root 874176 Nov 15  2010 /usr/lib/libstdc++.so.6.0.13

 

I searched a little bit in the Internet; seems that problem is a common problem. If you have a mini, maybe you can just copy the lib files over to the Soho. If it all does not help it seems we have to compile the executable again on the old Soho platform.

 

Unfortunately, I do not have a mini (unless you have one laying around that you would not mind tossing my way wink.gif). How long until a SoHo-platform executable gets cranked out?

 

BTW, thanks for all your quick (and helpful) responses!

Share this post


Link to post
Share on other sites

If you have a mini, maybe you can just copy the lib files over to the Soho. If it all does not help it seems we have to compile the executable again on the old Soho platform.

 

I only have the the snom ONE SoHo.

Share this post


Link to post
Share on other sites

We were actually so far under the impression that there was no difference between SoHo and mini... But because we did a fresh install on the tool chain, it seems that that broke the backward compatibility on the SoHo. Looks like we have to dig the SoHo out again and make another image there.

Share this post


Link to post
Share on other sites

We were actually so far under the impression that there was no difference between SoHo and mini... But because we did a fresh install on the tool chain, it seems that that broke the backward compatibility on the SoHo. Looks like we have to dig the SoHo out again and make another image there.

 

Do we have a time frame on this? My business is without a phone system now.

 

I am very unimpressed with your assumption, you should know your products and test them before releasing the update. Very Unprofessional.

Share this post


Link to post
Share on other sites

We have made a build on the SoHo distribution at http://www.snomone.c...trl-soho-5.0.2. Please use this one for the SoHo.

 

 

Hmm... still not working. These are the steps I followed:

 

1.) cd /usr/local/snomONE;

2.) wget http://www.snomone.com/downloads/snomONE/mini/pbxctrl-soho-5.0.2

3.) chmod a+rx pbxctrl-soho-5.0.2;

4.) mv pbxctrl pbxctrl-old;

5.) mv pbxctrl-soho-5.0.2 pbxctrl;

 

I then hard a difficult time restarting the PBX: Rebooting under the System tab didn't work; restarting the PBX service through the SoHo's Admin Interface did not work; service snomONE restart and service snomONE stop through SSH would not work; but was eventually able to restart the entire system through the SoHo's Admin Interface;

 

Now, my remote phone does not register and I can not access the PBX web login page, neither remotely or on the LAN. Through SSH, I ran ./pbxctrl --version and the system's response was: ./pbxctrl: /usr/lib/libstdc++.so.6: version `CXXABI_ARM_1.3.3' not found (required by ./pbxctrl)

 

Does it matter that the version I was upgrading from was 4.5.0.1090 Epsilon Geminids (snom ONE mini) and not snom ONE SoHo?

Share this post


Link to post
Share on other sites

For now, I would stick to command line. If you check out /etc/init.d/snomone is that pointing to the right executable? Some systems used the name "snomONE-ctrl" or so. Make sure that the name in the init.d directory is pbxctrl and nothing else.

 

What is the operating system? cat /etc/debian_version should show us what version is on that system.

 

/usr/local/snomONE/pbxctrl --version must print 5.0.2; if there is a error we still have a problem with the Linux version that is installed on that system. The image was compile on debian 5.0.3.

 

Again the easiest would be if you port forward the SSH port (22) and give us a remote login, then we can probably figure this out in minutes.

Share this post


Link to post
Share on other sites

For now, I would stick to command line. If you check out /etc/init.d/snomone is that pointing to the right executable? Some systems used the name "snomONE-ctrl" or so. Make sure that the name in the init.d directory is pbxctrl and nothing else.

 

What is the operating system? cat /etc/debian_version should show us what version is on that system.

 

/usr/local/snomONE/pbxctrl --version must print 5.0.2; if there is a error we still have a problem with the Linux version that is installed on that system. The image was compile on debian 5.0.3.

 

Again the easiest would be if you port forward the SSH port (22) and give us a remote login, then we can probably figure this out in minutes.

 

The name of the executable in /etc/init.d/snomONE is pbxctrl. Under /etc/init.d, I do not see pbxctrl (not sure if I understood your comment that "the name in the init.d directory is pbxctrl and nothing else.").

Per cat /etc/debian_version, the result is 5.0.8

Share this post


Link to post
Share on other sites

Thanks Pablo for giving us access. So you also need a new library version:

 

root@pbx:/usr/local/snomONE # wget http://www.snomone.com/downloads/snomONE/mini/libstdc++.so.6.0.13

root@pbx:/usr/local/snomONE # mv libstdc++.so.6 /usr/lib

 

root@pbx:/usr/local/snomONE # rm /usr/lib/libstdc++.so.6

root@pbx:/usr/local/snomONE # ln -s libstdc++.so.6.0.13 /usr/lib/libstdc++.so.6

 

After that it should *really* work.

Share this post


Link to post
Share on other sites

Thanks Pablo for giving us access. So you also need a new library version:

 

root@pbx:/usr/local/snomONE # wget http://www.snomone.c...tdc++.so.6.0.13

root@pbx:/usr/local/snomONE # mv libstdc++.so.6 /usr/lib

 

root@pbx:/usr/local/snomONE # rm /usr/lib/libstdc++.so.6

root@pbx:/usr/local/snomONE # ln -s libstdc++.so.6.0.13 /usr/lib/libstdc++.so.6

 

After that it should *really* work.

 

Drum roll, please....................................................................... and it DOES work; thanks!

Share this post


Link to post
Share on other sites

Hi,

 

I'm at the same stage as comment #8 - I can get to the admin page but not the pabx page and a non working snom soho. Do I just enter the commands in comment #18 or is there a little more to it?

 

thanks

Share this post


Link to post
Share on other sites

#18 addresses the problem that earlier version of the device were shipped with an older version of the library. Yes, you should be able to just copy and paste those commands.

Share this post


Link to post
Share on other sites

I'm having a bit of trouble with these commands.

 

The wget works and downloads the new library, but the command

 

mv libstdc++.so.6 /usr/lib

 

comes up with an error saying - mv: cannot stat `libstdc++.so.6': No such file or directory

 

any idea what the next step is?

 

thanks

Share this post


Link to post
Share on other sites

Well was the wget successful? Try if you can download it from your PC. You can use the "ls" command in Linux to see what files you have in your working directory.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...