The Google Chrome Sources entry /etc/apt/sources.list.d/google-chrome.sources contains the following line:
Architectures: amd64
Without it, apt update warns:
N: Skipping acquisition of configured file 'main/binary-i386/Packages', as repository 'https://dl.google.com/linux/chrome-stable/deb stable InRelease' doesn't support architecture 'i386'
The problem is that something — I have no clue what — keeps removing the Architectures line, and I have to keep replacing it. It happens multiple times per day, on both my desktop and laptop.
It’s sufficiently bad that I’ve written a script to fix it before running apt update and apt upgrade.
Do you have any sort of insight as to what is causing this, and why I need the Architectures line? I read something about a “strict” mode in Ubuntu, but I didn’t understand it and, unfortunately, didn’t think to save the link.
This “strict” mode seems to affect other items as well, e.g. when installing the eza app, I had to add arch=amd64 to its entry /etc/apt/sources.list.d/gierens.list (but nothing keeps removing that one’s entry, thankfully).
I would be happy with either preventing the Architectures line from being removed, or removing the “strict” whatever-that-is limitation.
What I’ve Tried:
I’ve searched and asked AI, without gaining comprehension or a solution.
I’ve uninstalled Chrome, removed the sources file, and reinstalled Chrome.
I believe it’s Chrome’s cron.daily script, google-chrome. There’s section where it sets the chrome’s google apt source. The snippet of the sources section in that script does not include an “Architectures” entry although it does include “arch=amd64” for a sources.list type file for chrome.
Also Chrome’s deb postinstall script sets up the sources, so after every update it might also change the sources back to what it sets in the script instead of what you set manually.
Thank you. I suppose that there’s no point in changing the cron, because Chrome will probably stick it back again.
In that case, I should report this. I don’t know where, so I’ll ask on the Chrome Reddit sub.
I imagine that if this affected everyone, there would be a huge noise, so I must be one of very few people. Do you have any idea why it affects me? I must have inadvertently changed a setting somewhere.
There’s some posts on AskUbuntu about it, although they were about Chrome’s scripts removing “arch=amd64” from google’s source.list.
Reading through the postinstall and cron scripts, I think Google is bit too invasive on modifying the system. The cron script for updating is just overkill when the default setting for apt’s daily systemd service is to do an update daily. The cron.daily script is really not needed so I’d consider just removing it or set the symbolic link to point to /dev/null. And I skimmed those script files so I may have missed somewhere in them to tell chrome not to replace already existing config files on the system. I don’t have it installed myself anymore, opting to go with the chromium snap.
If you don’t want to see the apt notice about skipping a i386 repo, you either use “-qq” (or maybe just “-q”) on the apt command line to quiet the output, or set “Apt::Get::Update::SourceListWarnings “false”;”
in a conf file in /etc/apt/apt.conf.d
Of course, that may quiet other useful notices, warnings, or errors so use that caution.
dpkg-divert is your friend her, it allows you to override files in packages with your own (if the cron script is actually a packaged file and not something like a “here doc” in shell generated from the postinst, it will only work with actual files shipped by the package)
Thanks. It didn’t occur to me to check Ask Ubuntu.
I agree that Chrome’s daily cron is overkill. Yesterday, I modified the script to add the Architectures line, and this morning it replaced the sources file with the corrected version. So, I’ll leave it at that for now, although I might consider your suggestion of symlinking to /dev/null.
I’m unsure how to check this (I use apt and dkpg regularly, but don’t understand them). The file is a script held in /opt/google/chrome/cron/google-chrome. For now, I’ll leave it with my current corrections.
I discovered the bug report, which is marked as fixed even though it isn’t! I don’t know how long it takes to percolate through the system.
Seems it is shipped as an actual file and not generated on the fly by the postinst script so you could use dpkg-divert on it to add a diversion to your own script (or to /dev/null) and dpkg will respect this during updates of the package and not touch your diversion.
Heh, I guess I should have bothered to read the comments at the top of the google cron script. Probably could have saved a little time in perusing the script to come up with a solution:
This functionality can be controlled by creating the $DEFAULTS_FILE and
setting “repo_reenable_on_distupgrade” to “true” or “false” as desired.
An empty $DEFAULTS_FILE is the same as setting it to “false”.
The $DEFAULTS_FILE also has a setting “repo_add_once” which can be set
to “false” to prevent the package install from adding the repo altogether.
So create the google-chrome file in /etc/default before installing and chrome’s postinstall script and cron script should avoid adding a repo which you can do manually.
on both of my Linux Mint machines. Every time I update chrome, it still overwrites /etc/apt/sources.list.d/google-chrome.sources and /etc/cron.daily/chrome, forcing me to make the changes again so I don’t receive the warning about i386 packages. A script is a great answer to the problem, if google refuses to fix it themselves, though another thing to consider is to stop using Chrome altogether until they do fix it and instead use another browser, like Firefox, or Brave, as these browsers are not adding to your headaches!
That’s puzzling. For me, yes, the update overwrites /etc/cron.daily/google-chrome (which is a symlink to /opt/google/chrome/cron/google-chrome), but using the solution from @gpmitch — which is what you appear to have used — has worked for me.
To be clear: You add those two lines (but with normal double-quotes, not smart ones as shown in your post, which is probably the forum’s doing) to the file /etc/default/google-chrome
FWIW, in Debian, and hence Ubuntu, that’d be a clear-cut policy violation and thus an RC bug. Plus, there isn’t any reason to do so whatsoever. They should just use a normal file in /etc and dpkg should do the rest. Once a user has modified that file, it’s verboten by policy to silently overwrite it.
Goes to show that 3rd party repos can be a basket full of surprises.