Koozali.org: home of the SME Server
Obsolete Releases => SME Server 9.x => Topic started by: mophilly on June 11, 2016, 10:29:14 PM
-
I am trying to apply the latest CentOS 6 updates to an SME 9 installation.
yum update --enablerepo=smecontribs,remi,epel
...
Error: Package: gd-last-2.2.1-2.el6.remi.x86_64 (remi)
Requires: libwebp.so.5()(64bit)
I do not know what to add or exclude to resolve the libwebp dependency.
Also, I opened a bug report for the contrib, https://bugs.contribs.org/show_bug.cgi?id=9579, just in case this needs to be handled as a bug.
-
Never update your server with epel and remi repos enabled
-
OK. Thank you, Stefano.
I tried from the web panel, which did not seem to work, and from the cli using "yum update" without the --enablerepo switch, all before running the command with the three repos.
It this correct?
yum update --enablerepo=smecontribs
-
Yes
-
Thanks, Stephano. I appreciate your help with this.
Sadly, "yum update --enablerepo=smecontribs" did not work. Same error. Do I need to disable the remi and epel repo's before running the update? If yes, then I simply reenable them after?
-
If you previously updated your server with those repos enabled, maybe you broke something.
Now I'm not in front of a pc
-
Understood.
Update: I found a note at centos.org that refers to the package the update appears to trip over, e.g. gd-last-2.1.1-2.el6.remi.x86_64.
https://www.centos.org/forums/viewtopic.php?t=54626
The article suggests that running "yum --disablerepo=\* --enablerepo=base,updates update" to allow centos repos to install properly.
I wonder whether this might succeed:
1. yum disablerepo / enablerepo as above
2. then "yum update"
3. If success, then "yum update --enablerepo=smecontribs"
4. If success, then update or reinstall the php scl package(s) from remi
-
A normal Koozali SME Server update is performed ONLY with:
yum update
Do NOT enable/disable any repo manually. Check if you have any non stock repo's enabled by default.
-
Thank you, RequestedDeletion.
What happened, which may not be clear from my original post, is this...
0. Several months ago I installed the software collection so I could support ownCloud on this server.
1. Today I ran the update from the server-manager panel. Update did not complete and I was returned to the server-manager top page. I didn't expect that, so...
2. I ran the update from the server-manager in case I did not click the final button. Again returned to top page.
3. using the cli, i ran "yum clean all" followed by "yum update". error reported.
4. I then tried 'yum update --enablerepo=smecontribs,remi,epel". same error reported.
So that is the path I followed and here I am, for better or worse.
-
What is the output of 'yum update'
What is the output of 'db yum_repositories show'
-
3. using the cli, i ran "yum clean all" followed by "yum update". error reported.
That should be 'yum clean all --enablerepo=*', to also clear all the non stock repo's.
-
Thank you, RequestedDeletion, for your assistance.
What is the output of 'yum update'
What is the output of 'db yum_repositories show'
The output of yum update is quite lengthy, as is the list of repo's.
yum repo list: http://pastebin.com/pXePB5sf
yup update output: http://pastebin.com/aMSCPGaL
The pastebin links will be deleted in seven days (18 June 2016) but I can provide them elsewhere if asked.
-
Does this plan look like it will succeed?
0. yum --disablerepo=* --enablerepo=base,updates update
1. yum clean all --enablerepo=*
2. then "yum update"
3. If success, then "yum update --enablerepo=smecontribs"
4. If success, then update or reinstall the php scl package(s) from remi
Critique encouraged. :-)
-
remi=repository- BaseURL=http://rpms.famillecollet.com/enterprise/6/remi/$basearch/
- EnableGroups=no
- Exclude=mysql*,php-*
- GPGCheck=yes
- GPGKey=http://rpms.famillecollet.com/RPM-GPG-KEY-remi
- Name=Remi - EL6
- Visible=yes
- status=enabled
The remi repository should be disabled.
db yum_repositories setprop remi status disabled
signal-event yum-modify
yum update
Why it is enabled by default is another question.
-
Mophilly
Good (& I believe recommended) practice is to always specify a packagename when using the --enablerepo=reponame switch
The package name would be that which is found in the specified repo.
That way you do not inadvertantly update other packages that SHOULD NOT be updated.
This particularly applies to other external repos
ie any repo OTHER THAN those recommended repos to be enabled by default for sme server & the sme contribs repo
eg
yum update packagename --enablerepo=remi
In some cases you can do a general yum update when specifying the --enablerepo=smecontribs switch, but keep in mind that that will update any & all contribs that you have installed for which there is an update package.
Opinions vary on this, some people here prefer to have all packages including contribs updated in the one go, others (including me) prefer to only update one contrib package at a time.
The reason being that if a single package causes a problem, then it is much easier to identify which package caused the issue (after an update), whereas if you update many contribs at once & then experience problems, it can be difficult (or more difficult) to find the culprit.
eg
yum update smeserver-dansguardian --enablerepo=smecontribs
will only update the smeserver-dansguardian package & any dependencies, if it is already installed.
-
Mark,
after you disable the remi repo ( and keep it for manually and independently update php56 which you use), I feel like the update should run fine.
However, it might occurs that you already have installed previously some package that should not have been, hence leaving an error trying to update. If so, just send us the following :
/sbin/e-smith/audittools/newrpms|grep remithis will allow to find non base rpm
as a reference, my SME9 with php-scl installed will return this :
# /sbin/e-smith/audittools/newrpms|grep remi
gd-last.x86_64 2.2.1-2.el6.remi @remi
libzip-last.x86_64 1.1.3-1.el6.remi @remi
php54.x86_64 2.1-4.el6.remi @remi
php54-php.x86_64 5.4.45-9.el6.remi @remi
php54-php-bcmath.x86_64 5.4.45-9.el6.remi @remi
php54-php-cli.x86_64 5.4.45-9.el6.remi @remi
php54-php-common.x86_64 5.4.45-9.el6.remi @remi
php54-php-enchant.x86_64 5.4.45-9.el6.remi @remi
php54-php-gd.x86_64 5.4.45-9.el6.remi @remi
php54-php-imap.x86_64 5.4.45-9.el6.remi @remi
php54-php-ldap.x86_64 5.4.45-9.el6.remi @remi
php54-php-mbstring.x86_64 5.4.45-9.el6.remi @remi
php54-php-mysqlnd.x86_64 5.4.45-9.el6.remi @remi
php54-php-pdo.x86_64 5.4.45-9.el6.remi @remi
php54-php-pear.noarch 1:1.10.1-4.el6.remi @remi
php54-php-pecl-zip.x86_64 1.13.2-1.el6.remi @remi
php54-php-process.x86_64 5.4.45-9.el6.remi @remi
php54-php-soap.x86_64 5.4.45-9.el6.remi @remi
php54-php-tidy.x86_64 5.4.45-9.el6.remi @remi
php54-php-xml.x86_64 5.4.45-9.el6.remi @remi
php54-runtime.x86_64 2.1-4.el6.remi @remi
php55.x86_64 2.1-5.el6.remi @remi
php55-php.x86_64 5.5.36-1.el6.remi @remi
php55-php-bcmath.x86_64 5.5.36-1.el6.remi @remi
php55-php-cli.x86_64 5.5.36-1.el6.remi @remi
php55-php-common.x86_64 5.5.36-1.el6.remi @remi
php55-php-enchant.x86_64 5.5.36-1.el6.remi @remi
php55-php-gd.x86_64 5.5.36-1.el6.remi @remi
php55-php-imap.x86_64 5.5.36-1.el6.remi @remi
php55-php-ldap.x86_64 5.5.36-1.el6.remi @remi
php55-php-mbstring.x86_64 5.5.36-1.el6.remi @remi
php55-php-mysqlnd.x86_64 5.5.36-1.el6.remi @remi
php55-php-pdo.x86_64 5.5.36-1.el6.remi @remi
php55-php-pear.noarch 1:1.10.1-4.el6.remi @remi
php55-php-pecl-jsonc.x86_64 1.3.9-1.el6.remi @remi
php55-php-pecl-zip.x86_64 1.13.2-1.el6.remi @remi
php55-php-process.x86_64 5.5.36-1.el6.remi @remi
php55-php-soap.x86_64 5.5.36-1.el6.remi @remi
php55-php-tidy.x86_64 5.5.36-1.el6.remi @remi
php55-php-xml.x86_64 5.5.36-1.el6.remi @remi
php55-runtime.x86_64 2.1-5.el6.remi @remi
php56.x86_64 2.1-5.el6.remi @remi
php56-php.x86_64 5.6.22-1.el6.remi @remi
php56-php-bcmath.x86_64 5.6.22-1.el6.remi @remi
php56-php-cli.x86_64 5.6.22-1.el6.remi @remi
php56-php-common.x86_64 5.6.22-1.el6.remi @remi
php56-php-enchant.x86_64 5.6.22-1.el6.remi @remi
php56-php-gd.x86_64 5.6.22-1.el6.remi @remi
php56-php-imap.x86_64 5.6.22-1.el6.remi @remi
php56-php-ldap.x86_64 5.6.22-1.el6.remi @remi
php56-php-mbstring.x86_64 5.6.22-1.el6.remi @remi
php56-php-mysqlnd.x86_64 5.6.22-1.el6.remi @remi
php56-php-pdo.x86_64 5.6.22-1.el6.remi @remi
php56-php-pear.noarch 1:1.10.1-4.el6.remi @remi
php56-php-pecl-jsonc.x86_64 1.3.9-1.el6.remi @remi
php56-php-pecl-zip.x86_64 1.13.2-1.el6.remi @remi
php56-php-process.x86_64 5.6.22-1.el6.remi @remi
php56-php-soap.x86_64 5.6.22-1.el6.remi @remi
php56-php-tidy.x86_64 5.6.22-1.el6.remi @remi
php56-php-xml.x86_64 5.6.22-1.el6.remi @remi
php56-runtime.x86_64 2.1-5.el6.remi @remi
Unless you have other packages voluntary isntalled from remi repo (phpmyadmin...) any package not in the list should be reversed to its base version, with only the base repo installed you could run
yum downgrade packagename
-
Thank you, RequestedDeletion, janet and Jean-Philippe.
One difference between the list provided by Jean-Philippe and my installation is the inclusion of pgsql. For each of the remi php collections, I have added pgsql, e.g. php54-php-pgsql.x86_64, 5.4.45-8.el6.remi, and php55 and php56.
Another difference is the version numbers. For example, in the php54 collection I have version 5.4.45-8.el6.remi while the same packages in Jean-Philippe's list are 5.4.45-9.el6.remi. Note the delta of version -8 and -9. Other packages have a similar relationship. My system has an earlier php55 package, 5.5.35-1.el6.remi, while Jean-Philippe's contains 5.5.36-1.el6.remi.
It appears, then, that I need to update my remi installations. I will disable the remi repo and run the update again. If that works as desired, I will attempt the update for remi.
-
I ran the following:
db yum_repositories setprop remi status disabled
signal-event yum-modify
yum update
signal-event post-upgrade; signal-event reboot
The yum update terminated normally. Server booted up and appears to be functioning normally. However, the server-manager panel reports that updates are available. The list of updates appears to be the same packages as was processed by the manual update.
Would running the update again from server-manager be an appropriate action?
-
I ran the following:
The yum update terminated normally. Server booted up and appears to be functioning normally. However, the server-manager panel reports that updates are available. The list of updates appears to be the same packages as was processed by the manual update.
Would running the update again from server-manager be an appropriate action?
The server-manager checks for updates once a day and sets a flag. You've beaten the server-manager by upgrading manually, so the flag is not set back yet. Check in a day again, or force in server-manager to check for updates.
-
Thank you, RequestedDeletion.
You wrote "or force in server-manager to check for updates". What control in server-manager would instigate this "forcing"? Run the "software installer" once more or something else?
-
Software installer -> change settings -> change nothing -> save
-
That worked. Many thanks, again. :-)
I am off to the php-scl update.
-
To recap this thread...
The CentOS updates were applied correctly once I disabled the remi repo in the SME db. For the new reader, the enabled repo's listed in the SME db should be limited to only those that are part of the standard distribution. Be mindful of this if and when you elect to add other packages.
Following that I ran the smeserver-php-scl update from smecontribs. That completed normally, with nothing in the log that seemed out of the ordinary.
I cannot yet update the packages from remi. The package gd-last-2.2.1-2.el6.remi.x86_64 has a dependency on libwebp.so.5. More on that after further investigation.
-
Considering this https://pkgs.org/search/Libwebp
I would say
yum update php56 --enablerepo=remi,epel
-
Thank you, Jean-Philippe.
Running the update for php56 did not provide a new result. It boils down to the gd-last package.
# yum update gd-last --enablerepo=remi,epel
...
Resolving Dependencies
--> Running transaction check
---> Package gd-last.x86_64 0:2.1.1-2.el6.remi will be updated
---> Package gd-last.x86_64 0:2.2.1-2.el6.remi will be an update
--> Processing Dependency: libwebp.so.5()(64bit) for package: gd-last-2.2.1-2.el6.remi.x86_64
--> Finished Dependency Resolution
Error: Package: gd-last-2.2.1-2.el6.remi.x86_64 (remi)
Requires: libwebp.so.5()(64bit)
I could not find a reference to libwebp in epel that appeared to match the error report.
-
Running the update for php56 did not provide a new result. It boils down to the gd-last package.
# yum update gd-last --enablerepo=remi,epel
1. You entered gd-last as package name, where as it was suggested to enter php56 as package name
2. You have not added the epel repo to you yum repositories (see wiki)
Try 'yum update php56 --enablerepo=remi --enablerepo=epel' and you will see the epel repo is unknown. Unless you already added it after posting your yum repositories.
-
Thank you, RequestedDeletion. I appreciate the assistance and I am sorry this is dragging on so long.
Regarding item 1, while it is true that my example referenced gd-last, I did run yum update for php56 as suggested before running the same command for gd-last.
Regarding item 2, you were correct. The epel repo was not part of the yum meta data although it was listed in the yum directory tree. I updated the yum data per the wiki. I followed that with "signal-event yum-modify", then "yum clean all --enablerepo=*" and epel is now listed (as disabled) when I run "db yum repositories show".
When I ran "yum update php56 --enablerepo=remi --enablerepo=epel" once more, yum reported that no packages are marked for update. The output of "yum list installed" shows the php54, php55 and php56 packages in red, which I assume means they should be updated. (As an aside, I also noted that webtatic 6-5 is in the same state although I don't recall specifically adding that package.)
Earlier in this thread it was suggested to use "yum downgrade <package name>". The versions of the php packages installed for smeserver-php-scl are older than those shown in Jean-Phillipe's example in this thread. So downgrade doesn't seem like the action to take now. The result of "yum update --enablerepo=smecontribs smeserver-php-scl" the result is also "no packages marked for update", although the yum update was also run yesterday and updates were applied.
Questions: would the update of smeserver-php-scl normally include the php packages? If yes, should I "downgrade" smeserver-php-scl and run update for it again?
Suggestions are most welcome.
-
Thank you, RequestedDeletion. I appreciate the assistance and I am sorry this is dragging on so long.
Regarding item 1, while it is true that my example referenced gd-last, I did run yum update for php56 as suggested before running the same command for gd-last.
Regarding item 2, you were correct. The epel repo was not part of the yum meta data although it was listed in the yum directory tree. I updated the yum data per the wiki. I followed that with "signal-event yum-modify", then "yum clean all --enablerepo=*" and epel is now listed (as disabled) when I run "db yum repositories show".
When I ran "yum update php56 --enablerepo=remi --enablerepo=epel" once more, yum reported that no packages are marked for update. The output of "yum list installed" shows the php54, php55 and php56 packages in red, which I assume means they should be updated. (As an aside, I also noted that webtatic 6-5 is in the same state although I don't recall specifically adding that package.)
Earlier in this thread it was suggested to use "yum downgrade <package name>". The versions of the php packages installed for smeserver-php-scl are older than those shown in Jean-Phillipe's example in this thread. So downgrade doesn't seem like the action to take now. The result of "yum update --enablerepo=smecontribs smeserver-php-scl" the result is also "no packages marked for update", although the yum update was also run yesterday and updates were applied.
Questions: would the update of smeserver-php-scl normally include the php packages? If yes, should I "downgrade" smeserver-php-scl and run update for it again?
Suggestions are most welcome.
then the full step would be
yum update php54* php55* php56* --enablerepo=remi,epel
-
Bingo! That worked.
Thank you, Jean-Philippe, and RequestedDeletion, janet and Stephano for the help on this issue. :-)
-
I took the liberty to document this : https://wiki.contribs.org/PHP_Software_Collections#Update
-
Bingo! That worked.
Remaining question is why the remi repo was set to enabled at all. This could have borked your server massively...
-
Remaining question is why the remi repo was set to enabled at all. This could have borked your server massively...
Operator error would be my guess. I will have a stern talk with myself about this. Humor aside, fortune may have smiled on me as the dependencies caused update to abort.