OK, last night I upgraded a server running 6.0 to 6.2

With the typical yum update command.

For some reasons I lost SSH connection in the middle of it.

When I logged back in it shows now under release being 6.2

But I don´t think or assume the upgrade was completed because now when trying to upgrade with yum again instead of getting the typical nothing to do message I get error of duplicated packages.

But it fails exactly here before showing the list of duplicated:
---> Package yelp.x86_64 0:2.28.1-8.el6 will be updated
---> Package yelp.x86_64 0:2.28.1-13.el6_2 will be an update
--> Processing Conflict: nss-3.13.1-6.el6_2.x86_64 conflicts curl < 7.19.7-26.el6
--> Finished Dependency Resolution
Error: nss conflicts with curl
You could try using --skip-broken to work around the problem
** Found 400 pre-existing rpmdb problem(s), 'yum check' output follows:
DeviceKit-power-014-3.el6.x86_64 is a duplicate with DeviceKit-power-014-1.el6.x86_64

I tried everything so far, skip broken, yum clean, rebuild, etc. Everything I searched in the forum I tried already and most topics I found where about a broken YUM in a failed upgrade, this is not the case here, Yum works.

What I can try (if I did not tried that before) ?

I was not aware that breaking an update was so easy. A power loss is what most people have when stuff like this happens, not me. I just lost SSH connection but the server never lost connection to the net or anything else, just losing the session broke it. How sensitive. Instead of just keep running it in the background...

Did you try `yum-complete-transaction` yet? Part of the yum-utils package.

Sure, I did that already and it says:

No unfinished transactions left.

The server says 6.2 as well and I don´t see anything wrong with it, but im sure it's not completely updated as running yum lists like 400 duplicated packages after the error (which probably are installed already) but before the error mentioned it lists packages with "will be updated"

It seems yum is not robust enough to resume the update even when no connectivity was lost at all, this was not a power failure, a system reboot, nothing but I just lost SSH connection for 2 seconds.

I dont remember this happening ever with prior Centos 6 version, not in 4, neither in 5, they always resumed the update or started from scratch. Sadly with Centos 6 so far I see nothing but problems, to the point I will skip it completely for most servers running 5 and wait for version 7. Maybe its me but 6 is not a lucky number, also the GUI there are allot of tools missing in version 6.

Now this failed update...well Im just with very bad luck with this new release.

To fix that, please download the rpmdup_remover.sh script, chmod 755 rpmdup_remover.sh and then, as root, execute it. Note that it runs in test mode by default.

Now do:

It is important that the yum update be done immediately after the script has been run in notest mode.

Quote:

Thanks but I think that did more harm then good.

Instead of the duplicate packages I think it completely broke the systems as now it shows

udisks-1.0.1-2.el6.x86_64 has missing requires of libpthread.so.0()(64bit)
udisks-1.0.1-2.el6.x86_64 has missing requires of libpthread.so.0(GLIBC_2.2.5)(64bit)
unique-1.1.4-2.el6.x86_64 has missing requires of libc.so.6()(64bit)
unique-1.1.4-2.el6.x86_64 has missing requires of libc.so.6(GLIBC_2.2.5)(64bit)
unique-1.1.4-2.el6.x86_64 has missing requires of libc.so.6(GLIBC_2.3.4)(64bit)
unique-1.1.4-2.el6.x86_64 has missing requires of libc.so.6(GLIBC_2.4)(64bit)
unique-1.1.4-2.el6.x86_64 has missing requires of libpthread.so.0()(64bit)
unique-1.1.4-2.el6.x86_64 has missing requires of libpthread.so.0(GLIBC_2.2.5)(64bit)
unique-1.1.4-2.el6.x86_64 has missing requires of librt.so.1()(64bit)

This are just a few ones, the list is long I could not possible paste them here.


Everything is missing.

Yes. I did run "yum update" inmeditately after the script.

So now running yum update will always give the same results when it tries to update.

I guess thats it, I have to reinstall the whole server now correct?

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.

When updating via ssh, use screen or tmux.

I think its fixed now.

There where mixed glib i686 packages installed which is wrong. I manually remove them, then reinstalled glib again and other packages, after that it was only complaining about arb packages which I again installed missing dependencies manually.

Now running yum update shows no error anymore and it gives me a list of 800+ packages to update.

I guess its fixed and I just need to update it now.

Is there something I can do to make sure that all packages are indeed Centos 6.2 after it?

I don´t use screen since years. I used it for a very long scrip job which had to be executed for 72 hours or so, for indexing a database, it was years ago and I remember losing SSH connection all the time so screen was the only solution. Thats when I learned about it ;)

Yes. That would prevent this indeed, but since it never happen to me before I never took that precautions to run it over screen.