Package Details: google-chrome 92.0.4515.107-1

Git Clone URL: (read-only, click to copy)
Package Base: google-chrome
Description: The popular and trusted web browser by Google (Stable Channel)
Upstream URL:
Keywords: chromium
Licenses: custom:chrome
Submitter: None
Maintainer: luzifer
Last Packager: luzifer
Votes: 2047
Popularity: 24.94
First Submitted: 2010-05-25 20:25
Last Updated: 2021-07-20 21:20

Sources (3)

Pinned Comments

luzifer commented on 2020-02-03 00:35

When reporting this package as outdated make sure there is indeed a new version for Linux Desktop. You can have a look at the "Stable updates" tag in Release blog for this. Do not report updates for ChromeOS, Android or other platforms stable versions as updates here.

This package will automatically get updated as soon as the Debian package is available. This is checked at least once per hour.

Latest Comments

1 2 3 4 5 6 ... Next › Last »

andrej commented on 2021-08-01 02:31

For some reason the current version doesn’t work at all on my desktop. No pages are loaded, just loading forever. There is no error message explaining what’s wrong. Also, all signs of hardware acceleration are switched off in chrome://gpu. Chromium works fine (and so do other browsers).

EDIT: google-chrome-beta has no such issue.

(BTW, the ideas around disabling systemd-resolved below are bad ideas. :-) Just sayin'.)

warmos commented on 2021-07-31 14:11

I can at least confirm that disabling systemd-resolved got me google-chrome running again

debohman commented on 2021-07-31 00:21

The simplest way is to just reinstall the old package with pacman. If you cd to the google-chrome repository on your system, you should see the older packages.

Just do (e.g.):

% sudo pacman -U google-chrome-91.0.4472.114-1-x86_64.pkg.tar.zst

Frnco commented on 2021-07-31 00:13

Downgrading is a very poor solution but does work.

1202's comment worked like a charm to me, so I made a one-liner in Bash that does it all, only asking for confirmation before removing the folder at the end, to ensure the one-liner has zero chances of deleting anything that shouldn't be deleted even if you mess with the environment variable (provided of course you use the same variable in the echo that asks for confirmation and in the rm command that actually deletes stuff). The Uppercase I in the rm is the option that prompts you for confirmation before deleting anything, while the lowercase r makes it recursive so it deletes the directory together with all its contents. The -c option in wget makes it try to continue the download if it failed previously, not strictly necessary but can help in some situations, while the -O - option means "output (-O) to stdout (-)", which pipes the contents of the file to stdout and we then pipe it into tar -xz (No need for the f option as there's no file, and the v option we usually include is just for verbosity which we also don't need. Then we cd into the folder, install using makepkg -si --boconfirm. Here -s syncs the deps and -i installs the package, while --noconfirm skips asking for confirmation, then we cd out of the folder, and finally ask the user for permission to remove the folder, which doubles as a way to make doubly sure nothing is removed by mistake.

$ hashedName=aur-710114824f61f1468346d7de4072dc041fac8177; wget -c$hashedName.tar.gz -O - | tar -xz && cd $hashedName && makepkg -si --noconfirm && cd .. && echo "Please confirm removal of folder $hashedName" && rm -rI $hashedName

If like me you use Fish Shell, setting the environment variable has to be done using Fish syntax, which is one of the reasons I included confirmation before removing anything, because when I was starting to use Fish I did run into problems when trying to run commands that I used without problem in bash but in Fish my environment variables were completely ignored and interpreted as empty strings.

Call it a trauma but yeah just to make thrice sure nobody ends up deleting anything by accident, here's a version that works in Fish Shell:

$ set hashedName aur-710114824f61f1468346d7de4072dc041fac8177; wget -c$hashedName.tar.gz -O - | tar -xz && cd $hashedName && makepkg -si --noconfirm && cd .. && echo "Please onfirm removal of folder $hashedName" && rm -rI $hashedName

If you think of a simpler way that is clearer than this and as simple to copy-paste it, please do tell.

1202 commented on 2021-07-30 09:51

Disabling systemd-resolved does not work for me, it messes with my other network connections. I downgraded to the latest version 91: wget then tar -zxvf aur-..., cd aur-... and makepkg -si.

b1tninja commented on 2021-07-29 18:07

You will have to disable systemd-resolved or downgrade to a systemd < 249 until version 93.

Messing with /etc/nssswitch.conf may be another option

redsolja commented on 2021-07-29 13:10

Google Chrome crashes/hangs, when using a default/vanilla Arch Linux system, with systemd-resolved enabled.

This should be fixed, as many of us use systemd-resolved.

Tyrin.price commented on 2021-07-23 02:07

My problem was resolved when I stopped and disabled dhcpcd.service ... that service is not needed for my setup.

nallekarhu commented on 2021-07-22 01:53

@koshikas Yeah, I'm not surprised, after all this is not your normal run of the mill git package.

FWIW, I have no problems with "google-chrome 92.0.4515.107-1" and systemd 249 after disabling systemd-resolved.

koshikas commented on 2021-07-22 01:07

the fix has been merged but will be only be available to the next build. they are not recalling the current build since, i quote;

"It seems Ubuntu is using systemd 247 in their most recent non-LTS and debian is using 247 in their testing branch. Fedora 34 is on 248 and probably won't be on 249 for a while. openSUSE tumbleweed isn't on it either. Those are our officially supported Linux distros. Definitely merge this to 93. But this is probably simple and safe enough to merge it to 92 given that it causes crashes for anyone using systemd 249."