Yesterday I did an online upgrade of my laptop from openSUSE 12.1 to 12.2, using this procedure. It was almost a painless process; however unfortunately something crashed the whole X session part-way through the upgrade so I had to manually re-run zypper dup from a virtual console to complete it. The procedure should probably warn about that scenario in some way, although there is no obvious clean solution, e.g. switching to runlevel 3 before starting the upgrade would probably kill the network when NetworkManager is in use. I also had some weirdness related to my encrypted /home partition (despite the advice in the release notes).

The final issue was Google Chrome failing to start with the following error:

/usr/bin/google-chrome: error while loading shared libraries: libbz2.so.1.0: cannot open shared object file: No such file or directory

It seems that this is at least in part due to a disagreement between Google engineers and Linux distros on what symlinks ldconfig should generate. If you look in the %post section of the google-chrome-stable rpm, you’ll see

# Most RPM distros do not provide libbz2.so.1.0, i.e.
# https://bugzilla.redhat.com/show_bug.cgi?id=461863
# so we create a symlink and point it to libbz2.so.1.
# This is technically wrong, but it'll work since we do
# not anticipate a new version of bzip2 with a different
# minor version number anytime soon.

I don’t have time to decipher openSUSE’s shared library packaging policy, but I assume it’s deliberate that /usr/lib64/libbz2.so.1.0 does not exist as a symlink even though /usr/lib64/libbz2.so and /usr/lib64/libbz2.so.1 do.
It has been suggested to me that this omission could be related to http://en.opensuse.org/openSUSE:Usr_merge. Regardless, google’s hack should have compensated for this, but for some reason (presumably related to the upgrade), there was a dangling symlink in /opt/google/chrome:

lrwxrwxrwx 1 root root 18 Sep 24 10:17 libbz2.so.1.0 -> /lib64/libbz2.so.1


This symlink is not owned by any rpm, which suggests that google’s hack might be in violation of the FHS for modifying a static and potentially read-only filesystem – although that’s moot since the modification would only happen at install-time at which point opt has to be mounted read-write anyway. Regardless, removing that dangling symlink and pointing it to /usr/lib64/libbz2.so.1 fixed the issue.