http://chrome.richardlloyd.org.uk/
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
install_chrome.sh 4.60 (12th April 2014 - use F17 libgnome-keyring.so.0 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 install_chrome.sh
./install_chrome.sh
The script has optional command line arguments - here's the output of "./install_chrome.sh -h":
Syntax: ./install_chrome.sh [-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
Version 4.60 (12th April 2014):
Latest Google Chrome prompted me for a keyring password, which I eventually realised was because of an undefined gnome_keyring_attribute_list_new symbol. Turns out this first appeared in an F17 library, so I've had to download F17's libgnome-keyring RPM and extract libgnome-keyring.so.0 from it. I had no idea people managed to get a CentOS 6 install with no nss package (must be some sort of minimal install I guess), so that's been added. Thanks to Ravi Saive at tecmint.com for suggesting this, though no-one actually told me the issue directly :-( Check the size and cksum of a downloaded Fedora RPM after the download as well as before (duh!).
Version 4.50 (11th December 2013):
If Google Chrome execs a helper app and that app then execs another sub-process, then LD_PRELOAD would mess up that second sub-process. This has been fixed by saving, unsetting and restoring LD_PRELOAD around the point where the helper app is exec'ed (an example would be file-roller viewing .tar.gz downloads). Previously downloaded F15 RPMs are now checksummed and size-checked on subsequent script runs. If they don't match, they are deleted and re-downloaded. This is a special non-raw-orphan-kitten-eating release just for a certain CentOS mailing list member :-)
Version 4.41 (9th December 2013):
A user reported that glibc-devel wasn't present (causing the gcc compilation to fail), so I've added this in as a dependency. Removed the SELinux warning at the end of the script because enforcing mode seems to not upset nacl_helper in recent Google Chrome releases. Fedora 15 RPMs have moved to the archive site, so adjusted the code to only download from the archive site. Primary testing is now with CentOS 6.5 and Scientific Linux 6.4.
Version 4.40 (5th October 2013):
The same user who reported the 4.30 issue found another missing symbol, this time in the Fedora 15 libgtk-x11-2.0 library. The symbol is defined in the Fedora 15 libgdk_pixbuf-2.0 library, so that is now extracted from the additionally downloaded Fedora 15 gdk-pixbuf2 RPM. The chrome-deps RPM is therefore now at version 1.03.
Version 4.30 (4th October 2013):
A user reported a missing symbol that was tracked down to the Fedora 15 libgio-2.0 library. That library and its libgobject-2.0 dependency are now additionally extracted and included in the chrome-deps RPM (which was bumped to version 1.02).
Version 4.20 (22nd August 2013):
If possible, use "yum check-update google-chrome-stable" ahead of the OmahaProxy CSV site to look for updates. Any newer version can be installed rather than insisting on the exact OmahaProxy version (after a full day being out-of-date after the Google Chrome 29 launch, we can't trust it not to happen on each new release). Used some extra params to the OmahaProxy request to narrow the data down more precisely. Google Chrome 29 doesn't wrongly output dbus messages like version 28 did, so the terminal warning was removed.
Version 4.10 (8th August 2013):
Fixed Google Talk (Hangouts) plugin crash by unsetting LD_LIBRARY_PATH when it's run (yes, for some reason, the plugin is built with an older toolchain than Google Chrome itself). Some users are reporting i686 is used in their RPM build path instead of i386 - I couldn't reproduce this, but I've added code to work around this anyway. modify_wrapper no longer outputs anything to stdout if it successfully updates /opt/google/chrome/google-chrome.
Version 4.01 (30th July 2013):
Emergency 2-char bug fix because I found a 4th build environment that triggered an rpmbuild bug (parses % directives on a commented line in a spec file). Removed the two percent chars on a comment line and it works again. No idea why my normal three build environments didn't show this problem (one of them is literally a VM image of a clean desktop right after an CentOS 6 install).
Version 4.00 (30th July 2013):
New chrome-deps RPM is built that includes 7 Fedora libraries (libdl.so.2 added for this release), unset_vars.so (updated slightly) and a modify_wrapper script that is run post-install to add code to /etc/default/google-chrome to modify google-chrome if its LD_PRELOAD addition isn't present. modify_wrapper will also enable the Google Chrome repo. Download/installation of google-chrome-stable/chrome-deps dependencies is now prompted for. Don't remove /etc/cron.daily/google-chrome or /etc/yum.conf.d/google-chrome.repo any more. Added -t (temp dir parent location) option and also -s (stable), -b (beta) and -U (unstable) options to switch release channels.
Version 3.20 (27th July 2013):
Compile and install LD_PRELOAD functions that wrap around exec*() routines, bringing in gcc as a new dependency. The functions save/blank LD_LIBRARY_PATH, call the original routines and, if they return, restore LD_LIBRARY_PATH. This is an initial effort to stop helper apps/plugins from crashing when run from within Google Chrome.
Version 3.11 (25th July 2013):
If SELinux is enabled, set appropriate SELinux contexts on Fedora libraries in /opt/google/chrome/lib and that directory itself. If SELinux is enabled and in enforcing mode, display a warning that permissive mode (with a reboot) is required to get nacl_helper to run correctly.
Version 3.10 (24th July 2013):
Use .so.0 extension (instead of .so.3 in earlier releases) for renamed Fedora ld-linux library. Also changed references to ld-linux*.so.0 in ld-linux, libc and libstdc++ Fedora libraries. Thanks to Marcus Sundberg for this suggestion. Dependency list for Google Chrome RPM is now redhat-lsb, wget, xdg-utils GConf2, libXScrnSaver and libX11 (1.5+). Hangs/errors occurred with a CentOS 6.0 VM I ran Google Chrome under, but 6.4 is fine, so that's now the mimimum OS version requirement (script offers to upgrade 6.0-6.3 to the latest release - if declined, the script aborts).
Version 3.00 (21st July 2013):
Added command line options at long last. -d will remove /tmp/chrome_install at the end of the script. -h shows syntax help. -n displays a dry run of what it would do without actually doing anything. -q reduces the output messages to the minimum needed and -q -q silences the output completely apart from fatal errors. -u uninstalls the Fedora libraries and the Google Chrome RPM. Abort script if it detects Google Chrome is running. Display disk/file usage (only if files are present) for /opt/google/chrome and /tmp/chrome_install at the start and end of the script. If it's defined, use $TMPDIR instead of /tmp. Install Fedora libraries before the Google Chrome RPM (was the other way around). Don't download Fedora RPMs and/or unpack them if the Fedora libraries are already installed in /opt/google/chrome/lib - this speeds up second and later runs (e.g. for Google Chrome upgrades) significantly.
Version 2.10 (20th July 2013):
Can detect if Fedora 15 RPMs have been moved to the archive site and will download from there instead if they have. Fixed incorrect check for lsb dependency. Remove a cron file and repo file installed by the Google Chrome RPM. Simplistic check that OS is an RHEL 6 derivative. Early exits now run clean up routine. Downloads all go through one function that will restore any pre-existing file if the download fails.
Version 2.00 (14th July 2013):
32-bit support added thanks to prodding from Seva Epsteyn. Version check both installed and downloaded Google Chrome against the OmahaProxy CSV list and only download/install if out-of-date. Use updated Fedora 15 RPMs rather than the original ISO versions. Warn if an enabled Google Chrome repo is present. General code tidy ups and more/readable messages are output now too.
Version 1.10 (13th July 2013):
Added auto-update check because the number of versions today is getting somewhat crazy. Also fixed an incorrect skip of force-installing a downloaded Chrome RPM (if any previous Chrome RPM had been installed, it would have never installed a new one!).
Version 1.02 (13th July 2013):
Added --no-check-certificate to wget command (my testing didn't need it, but someone reported that their wget did need it). Also yum install wget if it's not on the system.
Version 1.01 (13th July 2013):
Fixed the bad variable that plagued version 1.00.
Version 1.00 (13th July 2013):
Downloads latest Chrome and some Fedora 15 RPMs, installs lsb and some extracted libraries from the F15 RPMs. Had a last-minute bad variable added that broke the Chrome download completely. :-(
The TODO list
The first-time install and run of Google Chrome on a non-KDE system produces some xdg-mime errors. This is a bug in the xdg-utils package that I've reported to Red Hat, so you'll have to wait for them to fix it.
Exactly every two hours, Google Chrome tries to exec itself (I think to get its version or something) and this causes a segfault entry in /var/log/messages, probably due to LD_LIBRARY_PATH issues. I'm hoping to track this down and fix this in a future release.
On my CentOS 6 physical desktop with the closed source AMD Catalyst graphics driver, I get an "InitializeSandbox() called with multiple threads in process gpu-process" message on the console, but I don't see this on VMs that don't use the Catalyst driver. It looks like the browser isn't sandboxed and doesn't have hardware GPU acceleration either :-( Note that if Google Chrome (or Mozilla Firefox) crashes your Catalyst-driven desktop, this is an issue with the Catalyst driver and you should update to a version that doesn't crash the X server.
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
rklloyd@gmail.com 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:
Yes, Fedora 15/17 RPMs are indeed no longer updated, but none of the later Fedora releases have binary RPMs that work. There may be an alternative - download equivalent source RPMs from the latest Fedora and attempt to build the libraries from source. This is potentially a huge undertaking (tracking RPM updates, jumps of major Fedora versions and a much larger - and possibly fluctuating - dependency chain all give me nightmares!) and has no guarantee of success. Building that much source code could also massively lengthen the script running time and, no, I wouldn't host the built libraries here (bandwidth and trust issues...).
It's not clear to me at all why the LD_PRELOAD code I've written is "abuse". It's needed so that anything exec()'ed by Google Chrome (e.g. helper apps) doesn't use the Fedora 15/17 libraries that are intended strictly just to start up Google Chrome (via LD_LIBRARY_PATH).
To produce a single script that does everything (including root-only RPM installs) obviously requires root access. Yes, in theory, you could skip root-requiring actions if you're not root, but these are so intermingled in the code flow (e.g. you need to install some prequisite RPMs and even upgrade your OS if it's pre-6.4 before you even get to build the chrome-deps RPM), that it would be extremely clumsy to try to split root vs. non-root actions.
The script doesn't consume raw orphaned kittens - more like raw oprhaned Google build systems!
The ChromeDriver server (Web app developers only)
If you're a Web app developer and have just installed Google Chrome via my script, you may also be trying to run the ChromeDriver server on CentOS 6 to automate the testing of your app. Sadly, after downloading and unpacking it (and making sure you got the latest 32-bit or 64-bit version), you'll find it has a familiar library problem very similar to Google Chrome's. However, this is easily fixed by simply using the F15/F17 libraries from your Google Chrome installation:
export LD_LIBRARY_PATH=/opt/google/chrome/lib
./chromedriver
[Should output: Starting ChromeDriver (v2.9.248304) on port 9515]
The Chromecast
If you have a Chromecast, you can install the Google Cast extension in Google Chrome by going to the Extensions section of the Chrome Web store and searching for "Google Cast". You can then cast a tab from your CentOS 6 Google Chrome, though it can be laggy. More info (from a UK/Linux/Android perspective) about Chromecast can be found on my sister site.
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 1.0.55.7425 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 1.0.60.7918 and 1.0.71.8015 RPMs both crash on CentOS 6.4. I would strongly recommend you keep a copy of the working 1.0.55.7425 RPM, because Google may delete it at any time.