On 6 ianuarie 2016 18:49:32 EET, Ken Dreyer <kdreyer at redhat.com> wrote: >On Wed, Jan 6, 2016 at 7:24 AM, Bruno Martins <bruno.martins at 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.