How to install Google Chrome 28+ on CentOS 6

The problem

Sadly, the Google folks apparently think that the world's most popular commercial Linux (Red Hat Enterprise Linux aka RHEL) and its free equivalents (e.g. CentOS and Scientific Linux) are no longer worth supporting at all w.r.t. their Google Chrome browser.

Yes, they've dropped support for version 6.X of the above RHEL-based platforms from Google Chrome 28 onwards, despite the OSes being the latest release and fully supported by their respective maintainers until November 2020! It's equally bad that the latest Mozilla Firefox and Opera browsers run happily on the platforms, providing short shrift for any excuses the Google folks have come up with to justify their somewhat blinkered support stance.

I've built Chromium from regularly pulled source code in the past for CentOS 5 and it's a tough job on that platform and I didn't want to do it again for CentOS 6.

The solution

Luckily, there is a solution to this and it's not rocket science or that original either. You need to grab libraries from a more recent Linux distro, put them in a tree (/opt/google/chrome/lib) exclusively picked up by Google Chrome and then you can indeed run Google Chrome on CentOS 6.4 or later.

I've picked Fedora 15 and 17 RPMs to extract the libraries from because they're close to CentOS 6's libraries and the newest ones to actually work with the latest Google Chrome release on CentOS 6.

The download 4.60 (12th April 2014 - use F17 to fix keyring prompting, add nss to possible RPMs installed, error/exit if a downloaded Fedora RPM has the wrong cksum or size)

It's a bash shell script, so you run it as root as follows:

chmod u+x

The script has optional command line arguments - here's the output of "./ -h":

Syntax: ./ [-b] [-d] [-h] [-n] [-q] [-s] [-t tmpdir] [-u] [-U]

-b (or --beta) will switch to beta versions (google-chrome-beta).
-d (or --delete) will delete the temporary directory used for downloads
   if an installation was successful.
-h (or -? or --help) will display this syntax message.
-n (or --dryrun) will show what actions the script will take,
   but it won't actually perform those actions.
-q (or --quiet) will switch to "quiet mode" where minimal info is displayed.
   Specify -q twice to go completely silent except for errors.
-s (or --stable) will switch to stable versions (google-chrome-stable),
   which is the default if -b or -U haven't previously been specified.
-t tmpdir (or --tmpdir tmpdir) will use tmpdir as the temporary directory
   parent tree rather than $TMPDIR (if set) or /tmp.
-u performs an uninstallation of Google Chrome and chrome-deps rather the
   default action of an installation.
-U (or --unstable) will switch to unstable versions (google-chrome-unstable).

I would recommend you read the comments at the top of the script and inspect the code carefully since you need to run it as root. It will perform a fair number of downloads to obtain what it needs and if it finishes successfully, you should be able to run the "google-chrome" command (or select it from the Internet category in your GNOME main menu) as a non-root user.

The changelog

The TODO list

The compatibility note

Please note that CentOS 6 references on this page should hopefully equally cover all RHEL 6 derivatives. Note that I only use CentOS 6 myself so can't guarantee the compatibility with those other derivatives, but I do actually perform brief testing on a Scientific Linux 6 VM as well. Oh and someone's bound to ask - no, the script won't work with CentOS 5 or earlier.

Note that the RHEL 7 beta release that will eventually be the basis for CentOS 7 can run the latest Google Chrome out of the box without requiring my script to be run first. I will still maintain this script after CentOS 7 comes out, both for existing CentOS 6 users and also as a standby in case Google break their browser at some point on CentOS 7.

The feedback

Any bugs, fixes, improvements or suggestions should be fed back to me, Richard K. Lloyd, at but please note there is no warranty on this product whatsoever and the script itself is in the public domain. Bemusingly, one ultimate feedback was a tutorial video someone uploaded to YouTube!

The defence (no, it doesn't eat raw orphaned kittens)

Apparently one of the guys on the CentOS mailing list really doesn't like my script, claiming that it "consumes raw orphaned kittens" and "should be classified as a criminal offense". Here's my response:

The footnote: Google Music Manager rant

I just decided to see if I could upload some of my music collection to Google Play Music. And, no, I'm not paying £7.99 a month when I have a very large CD collection, a fair amount of which I've ripped to MP3s already.

Firstly, you can't upload MP3s from any phone or tablet, even one running Google's own Android OS or indeed a Chromebook running Chrome OS! Considering a large number of Google Play Music users will be playing back their music via an Android or Chrome OS device, it beggars belief that there isn't a way to upload that very same music from the device they'll listen to it on. Yes, I know Apple do the same obnoxious thing with their dreadful iTunes software (the Windows version of that is one of the most appalling pieces of software I've seen in years), but it still isn't an excuse for Google to follow the same dismal path Apple has trodden all these years.

Eventually, I discovered that there's a Google Music Manager you can download for Linux and there's even debs/RPMs in the same manner as Google Chrome has. Getting excited, I duly downloaded the Fedora 64-bit RPM, but it has an even newer toolchain used to compile it than Google Chrome does! And, no, you can't use a Fedora 19 VM to run the Google Music Manager either because Google won't let you, which is frankly ridiculous.

The solution I eventually found was on this German blog - Google still has some older RPMs you can download and run on CentOS 6. The 64-bit and 32-bit RPMs for version seem to work OK on CentOS 6.4. They have lsb and qtwebkit dependencies and there's some log4cxx message output on the console that you can ignore. The later and RPMs both crash on CentOS 6.4. I would strongly recommend you keep a copy of the working RPM, because Google may delete it at any time.