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
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
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.