Arch Linux User Repository

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.

You can also run this command to obtain the version string for the latest chrome version:

$ curl -sSf https://dl.google.com/linux/chrome/deb/dists/stable/main/binary-amd64/Packages | \
     grep -A1 "Package: google-chrome-stable" | \
     awk '/Version/{print $2}' | \
     cut -d '-' -f1

Do not report updates for ChromeOS, Android or other platforms stable versions as updates here.

so the latest in chrome video acceleration saga is, having merely --enable-features=VaapiVideoDecoder may not be enough. i'm on X11 and to get video acceleration functional, i need addition switch;

--disable-features=UseOzonePlatform.

ozone platform is enabled by default as of late in chrome, and for some reason disables video acceleration atleast on X11.

I'm trying to use Chrome to play streaming services videos. I can do Netflix, Amazon Prime Video, but not SlingTV. I can do it on the version of Google Chrome that you get from Google directly as a .deb and install in *buntu linuxes, but not the Arch AUR version. Any ideas what's missing?

This hardware involved is Intel NUC 1165G7 Iris GFX

@bulletmark, @kamilst96, @Nek.12, @hendry

i had my flags(set by the internal experimental flags) cease to function since 90. i could only enable hardware video acceleration by including flags in the .desktop (~/.local/share/applications/google-chrome.desktop) entry file under every Exec key;

Exec=/usr/bin/google-chrome-stable %U --enable-features=VaapiVideoDecoder

i suggest you try with your relevant flags

Video decode with vulkan on my T14s AMD GPU also doesn't work :/

https://s.natalian.org/2021-08-07/vulkan-disabled.png

Have the same issue as @kamilst96. Chrome ingores flags in chrome-flags.conf. Confirmed by the page chrome://version

Starting with Chrome 92, accelerated video decoding doesn't work with NVIDIA 470.57 driver - the image just smears on the screen. Anyone?

Relevant flags:

--enable-accelerated-video-decode

--enable-features=VaapiVideoDecoder

A trap with new version 92+ is that it does not ignore commented out options in ~/.config/chrome-flags.conf anymore.

92.0.4515.131-1 works with systemd-resolved.

But this issue still exists: https://aur.archlinux.org/packages/google-chrome/?O=20&PP=10#comment-818179

Latest build is working now for me also with nothing downgraded or disabled

@JoveYu Yes, it looks like it's working fine, for me anyway.

any one try new version 92.0.4515.131-1?

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

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

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

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 https://aur.archlinux.org/cgit/aur.git/snapshot/$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 https://aur.archlinux.org/cgit/aur.git/snapshot/$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.

Disabling systemd-resolved does not work for me, it messes with my other network connections. I downgraded to the latest version 91: wget https://aur.archlinux.org/cgit/aur.git/snapshot/aur-710114824f61f1468346d7de4072dc041fac8177.tar.gz then tar -zxvf aur-..., cd aur-... and makepkg -si.

You will have to disable systemd-resolved or downgrade to a systemd < 249 until version 93. https://bugs.chromium.org/p/chromium/issues/detail?id=1221442

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

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.

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

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

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

source: https://bugs.chromium.org/p/chromium/issues/detail?id=1221442#c23 https://bugs.chromium.org/p/chromium/issues/detail?id=1221442#c21

@bulletmark Hmm.. it looks to me that "chromium 92.0.4515.107-3" applies two fixes and removes the workaround in "chromium 92.0.4515.107-2", so it makes me think you don't need it.

@nallekarhyu, note that was the second commit applied to chromium. The first commit is required as well.

Now we just need an updated AUR package and we'll be set.

Fixed on chromium side.. "chromium 92.0.4515.107-3: upstream fixes for glibc and systemd"

I'm not sure if this is related to the other issues being reported here, but after updating to 92.0.4515.107 this morning I find that I can no longer print as the print dialog completely crashes Chrome. Rolling back to 91.0.4472.164 has made printing work again.

When trying to print, the dialog appeared briefly with a spinning blue circle where the destination printer should have been before crashing. Running from the terminal shows this:

$ google-chrome-stable
[4616:4616:0721/144506.411907:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process.
[4571:4571:0721/144511.137322:ERROR:print_preview_handler.cc(837)] Initiated PrintPreviewHandler::HandleGetInitialSettings()
[4571:4571:0721/144511.199407:ERROR:print_preview_handler.cc(529)] Initiated PrintPreviewHandler::HandleGetPrinters()
[4571:4571:0721/144511.216482:ERROR:print_preview_handler.cc(562)] Initiated PrintPreviewHandler::HandleGetPrinterCapabilities()
Segmentation fault (core dumped)

if you use yay, you can use package cache

cd ~/.cache/yay/google-chrome
yay -U google-chrome-91.0.4472.164-1-x86_64.pkg.tar.zst

Same issue here, also fixed by downgrading chrome.

The 'download' button on the AUR commit history page is incredibly useful.

@b3nn, you mean version 248.3-2, and yes that does fix it. But I suggest it is much more sensible to simply downgrade google-chrome.

Guys, try downgrading systemd-libs to 248-5. That fixed it for me.

my guess is that this only presents when using systemd-networkd as that is the only thing out of the ordinary on my system and related to networking.

I'm getting this network error too. First presented in the dev channel and after the last update I'm seeing it on stable.

Chrome does nothing since update to version 92. Broken.

after upgrade to 92, chrome cause 100% cpu and keep rising memory after start

I'm getting "Network service crashed, restarting service" too on 92.0.4515.107-1. Now I'm wondering how to downgrade since surprisingly 91 isn't in /var/cache/pacman/pkg ... guess it's because AUR. Doh.

I'm having the same problem: Network service crashed, restarting service.

@yochananmarqos well it's not just us two.

@bulletmark @the-k: I can't reproduce that. There must be something you both have in common on your system causing it.

92.0.4515.107 is broken for me too, getting "Network service crashed, restarting service." Downgrading systemd didn't help, downgrading Chrome to 91.0.4472.164 did.

New version 92.0.4515.107-1 locks up immediately for me when starting. Gone back to 91.0.4472.164-1 which is fine.

@noabody And the reason you would do that is which? That would break the chance for anyone to downgrade to an older version which is currently possible by just using an older PKGBUILD to build the package…

Apparently Google uses a single standard updated URL for the latest Debian version (beta, stable, unstable): https://dl.google.com/linux/direct/google-chrome-beta_current_amd64.deb https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb https://dl.google.com/linux/direct/google-chrome-unstable_current_amd64.deb

One could 'SKIP' the SHA check and do a blind build with version update like so:

source=("https://dl.google.com/linux/direct/google-chrome-${_channel}_current_amd64.deb")
pkgver() {
  tar -xf control.tar.xz './control' --to-command="grep -Pio '(?<=Version: )[\d\.]+'"
}

The Stable channel has been updated to 91.0.4472.164 for Windows, Mac and Linux but it's not picked up by automatic checker for this package. By manually setting pkgver to 91.0.4472.164 in the PKGBUILD the latest version is correctly installed.

@luzifer: Please match the optdepends() with chromium. libunity is deprecated and no longer builds, FYI.

ERROR:network_service_instance_impl.cc(331)] Network service crashed, restarting service.

Same here at systemd 249 (249-2-arch)

Using Chromium for now

Google Chrome stopped working after updating systemd to 249-3, the error is:

ERROR:network_service_instance_impl.cc(331)] Network service crashed, restarting service.

Seems like the issue is related to DNS resolving, as browser can still open simple pages if I use IP address.

Downgrading to systemd 248-3 resolves the issue. Meanwhile Chromium works totally fine with systemd 249-3.