How to install Google Chrome 28+ on RHEL/CentOS 6 or 7
developers seem to think that
Red Hat Enterprise Linux 6 - aka
RHEL 6 -
and its free equivalents
(e.g. CentOS 6 and
Scientific Linux 6)
are no longer worth supporting at all w.r.t. their
Google Chrome browser from
version 28 onwards.
This is mainly because Google are using very recent Linux build systems which
produce backwards-imcompatible binaries, which is not a wise move when
you're shipping closed source binaries.
It seems Google missed the fact that RHEL/CentOS 6 are both fully
by their respective maintainers until November 2020 (they're the only Linux
distros offering a decade of support). It's equally bad that the
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.
from regularly pulled source code in the past for
and it's a tough job
on that platform and I didn't want to do it again for
Note that RHEL/CentOS 7 users are also catered for, so please keep
reading if you're on that platform.
By using libraries from a more recent Linux distro and putting
them in a tree exclusively picked up by Google Chrome,
you can indeed run the latest Google Chrome on RHEL/CentOS 6.5 or later.
I've picked Fedora
to extract the libraries from because they're
close to RHEL/CentOS 6's libraries and the newest ones to actually work
with the latest Google Chrome release on RHEL/CentOS 6.
6.00 (27th July 2014 - handle new install trees for beta/unstable RPMs, fix for incorrect grep during beta/unstable RPM installs, new
PackageKit dependency, chrome-deps RPM renamed to chrome-deps-(stable|beta|unstable))
It's a bash shell script, so you download and run it as root as follows:
chmod u+x 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] [-f [-f [-f]]] [-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.
-f (or --force) forces an automatic "y" for any interactive prompting
except for OS mismatch/OS upgrade/reboot prompts. Specify -f twice to force
it for OS mismatches or OS upgrades as well and three times for reboots
on top of that.
-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 dropping of NPAPI support for plug-ins (especially Java)
In a stunningly stupid move, Linux Google Chrome 35 onwards no longer supports
the NPAPI plug-in protocol used by almost all browser plug-ins, instead
preferring the PPAPI protocol. The biggest impact this has is to
disable Java applets inside the browser, so if you need
to use Java applets regularly, I'm afraid I'd have to recommend switching
browsers (e.g. to Mozilla Firefox) until there's a Linux Java implementation
that supports PPAPI.
You can read more about this at the appropriate Google Chrome bugs (the
one and a
one), plus there's a developer
discussion about it. The claim is that less than 0.7% of
Linux Google Chrome users run NPAPI plug-ins regularly, so Linux was
deliberately targeted earliest (other platforms will drop support later in
2014). To be frank, this move is just as bad as dropping RHEL/CentOS 6 support
(though RHEL/CentOS 7 mostly fixes that) - why do this when there's
no Linux Java PPAPI support yet?
The crash on some systems
Some users (including me on my main desktop) have reported that
Google Chrome 36 crashes on their system and others (including me in a VM)
have been able to run that release fine.
I tried it on fairly untouched (just yum updated and nothing else) 32-bit
and 64-bit CentOS 6.5 GNOME desktop via VMs and live ISOs and sure enough,
it does actually run, albeit with buggy
error messages on the console. This means
something I've installed in my 64-bit CentOS 6.5 environment has caused version
36 to crash, whereas version 35 runs fine on it.
It's no big deal - I'll just add a "clean" 64-bit CentOS 6.5 VM to my testing
and I'll be moving to CentOS 7 at some point soon anyway.
- Version 6.00 (27th July 2014):
After many years installing into the same /opt/google/chrome tree for all
3 RPM releases (stable, beta, unstable), Google suddenly decided to split
the install trees. This meant a fair amount of new code was needed to
deal with this, although the dumb inclusion of the /usr/bin/google-chrome
soft-link in 3 RPM manifests means that the whole purpose of the split
(to allow all 3 RPM releases to be simultaneously installed) is ruined.
Added PackageKit as a new dependency (some live CentOS DVDs don't install
this package, but the Google Chrome RPM needs it). Fixed a bad grep
during the beta/unstable RPM install by creating a soft-link for
google-chrome.desktop. chrome-deps RPM has been renamed to
chrome-deps-(stable|beta|unstable) and any old-named chrome-deps RPM
will be removed. Removed the no longer needed CentOS 7 repo code.
Re-wrote the wrapper to handle all 3 RPM types because Google have
dubiously left the defaults for all 3 in the same /etc/default/google-chrome
- Version 5.02 (10th July 2014):
CentOS 7 final is out, so I removed the pre-release repo code and the
.repo file it created if it's present. Google Chrome will fail in any
pre-6.5 OS release, so refuse to continue if the user won't upgrade to 6.5
or later. Changed equivalent RHEL and CentOS references to be RHEL/CentOS.
- Version 5.01 (26th June 2014):
The latest pre-release CentOS 7 live ISO creates placeholder .repo files
which messed up the repo-creating code I'd put in 5.00. This has been
corrected by checking that the .repo files have at least one
non-blank/non-comment line in them (they don't at the moment!).
- Version 5.00 (21st June 2014):
Added initial 64-bit RHEL/CentOS 7
(pre-release) support that's been tested in a VM. This involved
possibly creating an updates repo file if no repos are found and not building
the chrome-deps RPM on RHEL/CentOS 7 of course. Upped the
minimum RHEL/CentOS 6 release supported by the script to version 6.5. Tidied up
some of the final messages output by the script.
- Version 4.70 (17th May 2014):
Finally fix the 2-hourly segfault that was appearing in syslog. It was a
self-call to the google-chrome bash script which was fixed by unsetting
LD_LIBRARY_PATH before the self-call. Steve Cleveland suggested a
non-interactive mode to allow the script to be cron'ed, so I added a -f
flag (specify up to 3 times depending on what prompting you want eliminated)
to provide this.
- 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 RHEL/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 a 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 minimum 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/CentOS 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
to Red Hat, so you'll have to wait for them to fix it.
- 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"
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 RHEL/CentOS 6 and 7
references on this page should hopefully equally cover all RHEL/CentOS 6 and 7
derivatives. Note that I only
use CentOS 6 myself (and CentOS 7 final in a VM) so can't guarantee
the compatibility with those other derivatives. Someone's bound to
ask: no, the script won't work with RHEL/CentOS 5 or earlier.
Any bugs, fixes, improvements or suggestions should be fed back to me,
Richard K. Lloyd, at firstname.lastname@example.org
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
someone uploaded to YouTube!
The defence (no, it doesn't eat raw orphaned kittens)
Apparently one of the guys on the CentOS
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 prerequisite RPMs and even upgrade
your OS if it's pre-6.5 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 RHEL/CentOS 6
to automate the testing of your app. Sadly, after
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:
[Should output: Starting ChromeDriver (v2.9.248304) on port 9515]
The non-solution at Red Hat's Customer Portal
I was bemused to find
this on the Red Hat Customer Portal. Basically, it says "Google Chrome doesn't install in RHEL 6", gives a bunch of failed yum install outputs and, er, that's it. Even funnier is
that the right hand side of the page says "This solution has been verified to work by Red Hat Customers and Support Engineers for the specified product version(s)." :-) Maybe they need to link to this page...
If you have a Chromecast, you can install the Google Cast extension
in Google Chrome by going to the Extensions
of the Chrome Web store and searching for "Google Cast". You can then
cast a tab from your RHEL/CentOS Google Chrome, though it can be laggy.
More info (from a UK/Linux/Android perspective) about Chromecast can be
found on my sister site.