On 6 ianuarie 2016 18:49:32 EET, Ken Dreyer kdreyer@redhat.com wrote:
On Wed, Jan 6, 2016 at 7:24 AM, Bruno Martins bruno.martins@rumos.pt wrote:
I've used the tool with '--force' parameter and it upgraded just
fine. Now I'm having some side effects like:
"grep: error while loading shared libraries: libpcre.so.0: cannot
open shared object file: No such file or directory"
I had a similar issue with grep when I upgraded my CentOS 6 home server to CentOS 7 last week. As explained elsewhere, the issue is that not all .el6 packages get upgraded.
To fix it, after I did the OS upgrade to CentOS 7:
- Generate a list of all packages with "rpm -qa",
- Note each of the ".el6" ones,
- Download the ".el7" equivalents from a CentOS mirror by hand,
- Install the .el7 versions with "rpm --force" (so RPM thinks you have
both versions installed)
- Use yum to remove the ".el6" versions.
There are some packages like python-argparse that don't have a direct equivalent in CentOS 7 (the argparse library is provided by the core python-2.7 package), so those are simply safe to remove outright. You might find that there's other crufty el6 packages left behind on your server that you don't need.
I host my OS (/boot and /) on software RAID1 (with mdadm), and for a while, the first el7 kernel I installed didn't add both drives to the array devices during boots, which made me wonder if the drives were dying. But it just turned out to be a software issue (maybe something in the very first initrd generation went awry?), because after I ran "yum update" to get the latest el7 kernel, it worked fine.
Once you finish the OS upgrade, if you see problems during operation, start with checking "rpm -qa" for "el6" and then working through the individual packages one-by-one. (you'll probably want to start with fixing "grep", since it's tedious to work without it :)
And once you find out that you have to do all those manually, you might as well ditch the upgrade tool altogether.