Sangoma 7 upgrade script failing

Beta Program Issues
20

Hi Bryan!

No…

Sorry, from time to time it most likely shows that English is not my native language…

What I wanted to say was

  • Was the problem fixed for her/him after he removed the package? I would try it but I won’t be able to for at least 6 more hours (my test system is at home…).
  • I see in the logs that I provided in the ticket that I seemed to have the same problem that he has (and one more with gnome-disk…)
  • I tried to run yum manually, ie not from the upgrade script, with the “–skip-broken” switch since this is what yum was suggesting me to do. It didn’t work as yum was apparently trying to download additional packages and name resolution doesn’t work on my system right now (and the network card is up).

I know that the outbound DNS traffic (port 53 UDP and TCP) is allowed by my firewall (and I even relaxed my rules to even more than they were) so I know it’s not a firewalling problem.

If I had to guess I would think it’s a problem with the wrong version of libresolv being used or something like that as everything else seems OK confguration-wise…

I replied to your question on the ticket, I use

127.0.0.1
8.8.8.8
172.16.2.1

First one is the one you (FreePBX devs) suggest putting first IIIRC, I believe it’s a DNS cache…
Second one is one of Google’s DNSes…
Third one is a DNS forwarder provided by my firewall… (pfSense)

Normally 172.16.2.1 would be before Google’s DNS but I had been testing something…

I tried to comment out 127.0.0.1 just in case there might be a problem with it and it made no difference (anyway it should have fallen back by itself to the others by itself but I just wanted to be it was not to blame…

Thank you and have a nice day!

Nick

21

@Marbled You should be able to remove nodejs-docs as thats included with the nodejs rpm we are using in the new SNG7 distribution. As for the DNS, still not sure why that’s happening yet.

22

Hi Bryan!

That’s what I intended to do when I get home though I am not sure if it will help in my case since “–skip-broken” should have helped with this I think…

I am assuming conflicting librairies…

(Though if I have library problems on this system other things should be affected…)

The config seems ok though I guess if removing the package and rebooting the system doesn’t fix it for me I might try manually retyping the content in case something in the file prevents it from being parsed correctly…

The thing I don’t get is why this doesn’t always happen…

I guess in my case the improper subnet mask problem I had (and the fact the new distro doesn’t like in one bit while the old one didn’t complain) caused something quite unplanned at what is most likely a critical step but nobody help reported something like that (at least yet!) so what caused this problem for the others, I wonder…

Thank you and have a nice day!

Nick

23

@Marbled - YES removing nodejs-docs fixed the problem and I was able to complete the upgrade. FYI - I also had to manually remove the vmware stuff (yum remove vmware*)

24

I am hitting a similar issue but I don’t see the problem being nodejs-docs (I could be reading the logs wrong), and I see now indication of DNS issues.

Here is a link to the ticket.

https://issues.freepbx.org/browse/FREEPBX-15490

25

Hi!

You have it and more possible problems, is mongodb usually part of the distro? (can’t check right now…)

Error: php-mysql conflicts with php56w-mysqlnd-5.6.31-2.sng7.x86_64
Error: Package: mongodb-server-2.4.14-4.el6.i686 (@pbx/6)
           Requires: libboost_program_options-mt.so.5
           Removing: boost-program-options-1.41.0-25.el6.centos.i686 (@updates/6)
               libboost_program_options-mt.so.5
           Updated By: boost-program-options-1.53.0-26.el7.i686 (sng-base)
               Not found
Error: php56w-common conflicts with php-common-5.4.16-42.el7.x86_64
Error: nodejs-docs conflicts with 2:nodejs-8.1.4-2.14.x86_64
Error: Package: 1:v8-3.14.5.10-9.el6.i686 (@pbx/6)
           Requires: libicuuc.so.42
           Removing: libicu-4.2.1-9.1.el6_2.i686 (@base/6)
               libicuuc.so.42
           Updated By: libicu-50.1.2-15.el7.i686 (sng-base)
              ~libicuuc.so.50
Error: Package: mongodb-server-2.4.14-4.el6.i686 (@pbx/6)
           Requires: libboost_system-mt.so.5
           Removing: boost-system-1.41.0-25.el6.centos.i686 (@updates/6)
               libboost_system-mt.so.5
           Updated By: boost-system-1.53.0-26.el7.i686 (sng-base)
               Not found
Error: Package: 1:v8-3.14.5.10-9.el6.i686 (@pbx/6)
           Requires: libicui18n.so.42
           Removing: libicu-4.2.1-9.1.el6_2.i686 (@base/6)
               libicui18n.so.42
           Updated By: libicu-50.1.2-15.el7.i686 (sng-base)
              ~libicui18n.so.50
Error: Package: 1:v8-3.14.5.10-9.el6.i686 (@pbx/6)
           Requires: libicudata.so.42
           Removing: libicu-4.2.1-9.1.el6_2.i686 (@base/6)
               libicudata.so.42
           Updated By: libicu-50.1.2-15.el7.i686 (sng-base)
              ~libicudata.so.50
Error: Package: mongodb-server-2.4.14-4.el6.i686 (@pbx/6)
           Requires: libboost_thread-mt.so.5
           Removing: boost-thread-1.41.0-25.el6.centos.i686 (@updates/6)
               libboost_thread-mt.so.5
           Updated By: boost-thread-1.53.0-26.el7.i686 (sng-base)
               Not found
Error: Package: mongodb-server-2.4.14-4.el6.i686 (@pbx/6)
           Requires: libboost_iostreams-mt.so.5
           Removing: boost-iostreams-1.41.0-25.el6.centos.i686 (@updates/6)
               libboost_iostreams-mt.so.5
           Updated By: boost-iostreams-1.53.0-26.el7.i686 (sng-base)
               Not found
Error: Package: mongodb-server-2.4.14-4.el6.i686 (@pbx/6)
           Requires: libboost_filesystem-mt.so.5
           Removing: boost-filesystem-1.41.0-25.el6.centos.i686 (@updates/6)
               libboost_filesystem-mt.so.5
           Updated By: boost-filesystem-1.53.0-26.el7.i686 (sng-base)
               Not found
 You could try using --skip-broken to work around the problem

Good luck and have a nice day!

Nick

26

Hi!

Thank you! I will try this as well as soon as I get home…

[quote=“ldkeen, post:23, topic:43145, full:true”]FYI - I also had to manually remove the vmware stuff (yum remove vmware*)
[/quote]

My system is not a vm but that’s good to know. Thank you!

Thank you and have a nice day!

Nick

27

I am not sure if it is usually part of the distro or was added as part of XMPP (Just came up in a search).

28

Hi!

I just checked (in the logs I posted on my ticket) and I had it in my logs as well but not as a problem… Weird…

For me what I saw in the logs was the Sangoma 7 version, not a conflicting version like what you have…

And what about the libboost packages which mongodb seems to depend on? Most of the entries you have in your logs seem to depend on them…

Good luck and have a nice day!

Nick

29

Mongodb is added for xmpp however it should be replaced as part of the upgrade with the SNG7 version which looks like it’s happening for some But not all.

30

OK, I removed the nodejs-docs package and it’s doing something different now…

I looked into post_sngupdate and the last line there for now is

yum -y shell /tmp/upgrade_transaction.yum

It has been there for a while now, I would say more than 30 minutes but maybe that’s normal for such an old computer…

I am working on another PC right now and continuously pinging it to see if it comes up but I will go see later if something else got added to the log…

Have a nice day!

Nick

31

Yes it will take a very long time at the end of the process while it renames and checks everything. @xrobau can give more details

32

Unfortunately there was a power failure and it restarted at one of the earlier steps…

Before that happened I did notice that the script had went much further…

If this works then maybe the problem is broken dependencies but what is weird is that what works for someone might not work for someone else (like for mongodb).

I tried –skip-broken but simply has an argument to a normal yum upgrade which is, obviously, not how the upgrade script calls yum so maybe –skip-broken might work if it was added to the upgrade script…

I saw no errors in the logs so it looks like what had run/is running doesn’t need network connectivity. Hopefully once everything has completed maybe it will be restored…

It looks like I won’t know if it has worked until tomorrow as it is now time for me to go to sleep and it has not completed yet…

I will keep you posted about the outcome…

Thank you and have a nice day!

Nick

33

Hi Andrew!

That box makes a good test system but it’s underpowered by today’s standard so I will only know tomorrow if things worked…

I will try to take a look at it before I leave for work…

Thank you and have a nice day!

Nick

34

The good news is repeating things, doesn’t seem to make a difference. I just tried upgrading the same machine again and it did the same thing. So at least it is a repeatable experiment…

35

Hello Bryan

I have had the same issue with Idkeen and Marbled EXACTLY. I did “yum remove nodejs-docs” and “yum update --skip-broken” and it progressed. However when it stopped and i log in I get:
PHP Fatal error: Incompatible file format: The encoded file has format major ID 4, whereas the Loader expects 7 in /var/www/html/admin/modules/sysadmin/agi-bin/LoadLicenseIfExists.php on line 0
Whoops\Exception\ErrorException: Incompatible file format: The encoded file has format major ID 4, whereas the Loader expects 7 in file /var/www/html/admin/modules/sysadmin/agi-bin/LoadLicenseIfExists.php on line 0
Stack trace:

  1. () /var/www/html/admin/modules/sysadmin/agi-bin/LoadLicenseIfExists.php:0

I have tried to do “yum clean metadata” and then “yum update” in case it didn’t complete and i get:
Loaded plugins: fastestmirror, kmod, versionlock
sng-base | 3.6 kB 00:00:00
sng-epel | 4.3 kB 00:00:00
sng-extras | 3.4 kB 00:00:00
sng-pkgs | 3.4 kB 00:00:00
sng-updates | 3.4 kB 00:00:00
(1/8): sng-base/7/x86_64/group_gz | 155 kB 00:00:00
(2/8): sng-epel/7/x86_64/group_gz | 170 kB 00:00:00
(3/8): sng-extras/7/x86_64/primary_db | 190 kB 00:00:01
(4/8): sng-epel/7/x86_64/updateinfo | 794 kB 00:00:03
(5/8): sng-pkgs/7/x86_64/primary_db | 419 kB 00:00:02
(6/8): sng-base/7/x86_64/primary_db | 5.6 MB 00:00:04
(7/8): sng-epel/7/x86_64/primary_db | 4.8 MB 00:00:05
(8/8): sng-updates/7/x86_64/primary_db | 7.7 MB 00:00:11
Loading mirror speeds from cached hostfile
No packages marked for update

None of the fwconsole commands is working
Any ideas?
Thank you in advance

36

Hi!

It did not switch to the right version of PHP…

re:

https://zend18.zendesk.com/hc/en-us/articles/217545597--Incompatible-file-format-PHP-Fatal-Error-With-Encoded-Files

Good luck and have a nice day!

Nick

37

It failed… :disappointed:

What I had on the screen was essentially what I had here:

and in the logs the last line I had was

yum -y upgrade

Looks like I will be reinstalling FreePBX 13 distro on that box this weekend… Let’s hope that backup works…

(It has a pretty complex setup for a home test server, not a setup I would like to redo, at least right now…)

Even if it had worked I was tempted to update the hardware because of a few things I noticed I wanted to improve but I don’t currently have the replacement hardware and I don’t want to unnecessarily use up my resets (which I assume I will have to do) since that box does have a few commercial modules even if it’s my home test server.

I have to go prepare to leave for work so things will stay as they are for like another 12 hours or so and most likely more if nobody has anything else to suggest doing…

Thank you and have a nice day (and good luck to people in the same situation that I am or that want to try to update anyway knowing the risks…)!

Nick

38

Thanks for the answer Marbled.
here’s the version i have:
PHP 5.6.31 (cli) (built: Jul 18 2017 16:13:04)
Copyright © 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright © 1998-2016 Zend Technologies
with Zend Guard Loader v3.3, Copyright © 1998-2014, by Zend Technologies
with Zend OPcache v7.0.4-dev, Copyright © 1999-2015, by Zend Technologies

any suggestions on how to tackle
thanks

39

Actually, I believe the answer is a little more complex than that…

IiRC the Zend stuff is what is used to encode the commercial modules so that you cannot see their source code like you would normally do for something written in PHP…

I think that there is a mismatch somewhere in the PHP/Zend version and what is currently active doesn’t recognize the version of what it is asked to execute because it is a more recent version than what it is able to handle…

At least that is my interpretation of this but I am no PHP guru…

You can get a similar problem with Java when you compile into byte code with a more recent version of Java than the one you are trying to run the resulting class file with…

Have a nice day,!

Nick