Re: Centos 6.0 upgrade to 6.2 broken?

Posted by nibb on 2012/2/28 15:08:32

I noticed that most where complaining about "glibc" so I installed manually and it installed it with 12 other packages.

Now yum is more or less in the same error we where before, except with allot of missing dependencies.

In particulart it starts with errors here:
-> Running transaction check
---> Package abrt.x86_64 0:1.1.13-4.el6 will be updated
--> Processing Dependency: abrt = 1.1.13-4.el6 for package: abrt-plugin-logger-1.1.13-4.el6.x86_64
--> Processing Dependency: abrt = 1.1.13-4.el6 for package: abrt-plugin-rhtsupport-1.1.13-4.el6.x86_64
---> Package libgcc.x86_64 0:4.4.6-3.el6 will be installed
--> Finished Dependency Resolution
Error: Package: abrt-plugin-rhtsupport-1.1.13-4.el6.x86_64 (@anaconda-CentOS-201106060106.x86_64/6.0)
Requires: abrt = 1.1.13-4.el6
Removing: abrt-1.1.13-4.el6.x86_64 (@anaconda-CentOS-201106060106.x86_64/6.0)
abrt = 1.1.13-4.el6
Updated By: abrt-2.0.4-14.el6.centos.x86_64 (base)
abrt = 2.0.4-14.el6.centos
Error: Package: abrt-plugin-logger-1.1.13-4.el6.x86_64 (@anaconda-CentOS-201106060106.x86_64/6.0)
Requires: abrt = 1.1.13-4.el6
Removing: abrt-1.1.13-4.el6.x86_64 (@anaconda-CentOS-201106060106.x86_64/6.0)
abrt = 1.1.13-4.el6
Updated By: abrt-2.0.4-14.el6.centos.x86_64 (base)
abrt = 2.0.4-14.el6.centos
You could try using --skip-broken to work around the problem
** Found 168 pre-existing rpmdb problem(s), 'yum check' output follows:
abrt-1.1.13-4.el6.x86_64 has missing requires of libgcc_s.so.1()(64bit)
abrt-1.1.13-4.el6.x86_64 has missing requires of libgcc_s.so.1(GCC_3.0)(64bit)
abrt-addon-ccpp-1.1.13-4.el6.x86_64 has missing requires of libgcc_s.so.1()(64bit)
abrt-addon-ccpp-1.1.13-4.el6.x86_64 has missing requires of libgcc_s.so.1(GCC_3.0)(64bit)
abrt-addon-kerneloops-1.1.13-4.el6.x86_64 has missing requires of libgcc_s.so.1()(64bit)
abrt-addon-kerneloops-1.1.13-4.el6.x86_64 has missing requires of libgcc_s.so.1(GCC_3.0)(64bit)
abrt-addon-python-1.1.13-4.el6.x86_64 has missing requires of libgcc_s.so.1()(64bit)

Now before the script they where problems with duplicates. Now they are with missing.

But the rpmdb problems are still here as far as I can see.

And when I try to install also the missing libgcc I get:

[root@altair download]# yun install libgcc.x86_64
-bash: yun: command not found
[root@altair download]# yum install libgcc.x86_64
Loaded plugins: fastestmirror, refresh-packagekit
Loading mirror speeds from cached hostfile
* base: mirror.ubiquityservers.com
* extras: mirror.raystedman.net
* updates: dist1.800hosting.com
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package libgcc.x86_64 0:4.4.6-3.el6 will be installed
--> Finished Dependency Resolution
Error: Protected multilib versions: libgcc-4.4.6-3.el6.x86_64 != libgcc-4.4.4-13.el6.i686
You could try using --skip-broken to work around the problem
** Found 168 pre-existing rpmdb problem(s), 'yum check' output follows:
abrt-1.1.13-4.el6.x86_64 has missing requires of libgcc_s.so.1()(64bit)
abrt-1.1.13-4.el6.x86_64 has missing requires of libgcc_s.so.1(GCC_3.0)(64bit)
abrt-addon-ccpp-1.1.13-4.el6.x86_64 has missing requires of libgcc_s.so.1()(64bit)
abrt-addon-ccpp-1.1.13-4.el6.x86_64 has missing requires of libgcc_s.so.1(GCC_3.0)(64bit)
abrt-addon-kerneloops-1.1.13-4.el6.x86_64 has missing requires of libgcc_s.s
......continues.


Of course --skip-broken will have 0 effect either.

If you ask me personally, an update should be reverted inmediatelly when something goes wrong or stop. Losing SSH connection is not something critical and can happen to anyone. Updating shoud be more robust, specially when we are talking this is supposed to be a new and more advanced version compared to 5x.

Sure most people don´t upgrade via a SSH console, but my guess is that with CentOS the case is allot of them do, as CentOS just like Red Hat is a datacenter OS so its used mostly and servers and said this its updated mostly remotely.

I think I should be aware of this and next time update via the KVM or direct console vs trying it via a SSH connection again. I never imagined that closing the session would cause such troubles.