New issue
Advanced search Search tips

Issue 850026 link

Starred by 1 user

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Bug



Sign in to add a comment

Initial Chrome RPM installation on Fedora fails to add signing keys

Project Member Reported by raphael....@intel.com, Jun 6 2018

Issue description

I've recently set up some fresh new Fedora installations (both 27 and 28), and installed Google Chrome Beta (67.0.3396.62) by downloading them from the official location (aka google-chrome-beta_current_x86_64.rpm).

In both installations, both `rpm -Uvh <package.rpm>' and `dnf install <package.rpm' yield the same result: the package is installed correctly, but the post-installation task fail to run.

Running transaction
  Preparing        :
  Running scriptlet: google-chrome-beta-67.0.3396.62-1.x86_64
  Reinstalling     : google-chrome-beta-67.0.3396.62-1.x86_64
  Running scriptlet: google-chrome-beta-67.0.3396.62-1.x86_64
error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Resource temporarily unavailable)
error: /tmp/google.sig.q4PNWC: key 1 import failed.
error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Resource temporarily unavailable)
error: /tmp/google.sig.q4PNWC: key 2 import failed.
Redirecting to /bin/systemctl start atd.service
  Running scriptlet: google-chrome-beta-67.0.3396.62-1.x86_64
  Erasing          : google-chrome-beta-67.0.3396.62-1.x86_64
  Running scriptlet: google-chrome-beta-67.0.3396.62-1.x86_64
  Verifying        : google-chrome-beta-67.0.3396.62-1.x86_64
  Verifying        : google-chrome-beta-67.0.3396.62-1.x86_64                                                                                                                                                   

Running `dnf reinstall <package.rpm>' doesn't help, and it is only when I run `dnf reinstall google-chrome-beta' (ie. by package name, not actual file) that things run correctly:

warning: /var/cache/dnf/google-chrome-beta-eb0d6f10ccbdafba/packages/google-chrome-beta-67.0.3396.62-1.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 7fac5991: NOKEY
Importing GPG key 0x7FAC5991:
 Userid     : "Google, Inc. Linux Package Signing Key <linux-packages-keymaster@google.com>"
 Fingerprint: 4CCA 1EAF 950C EE4A B839 76DC A040 830F 7FAC 5991
 From       : https://dl.google.com/linux/linux_signing_key.pub
Is this ok [y/N]: y
Key imported successfully
Importing GPG key 0xD38B4796:
 Userid     : "Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com>"
 Fingerprint: EB4C 1BFD 4F04 2F6D DDCC EC91 7721 F63B D38B 4796
 From       : https://dl.google.com/linux/linux_signing_key.pub
Is this ok [y/N]: y
Key imported successfully
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :
  Running scriptlet: google-chrome-beta-67.0.3396.62-1.x86_64
  Reinstalling     : google-chrome-beta-67.0.3396.62-1.x86_64
  Running scriptlet: google-chrome-beta-67.0.3396.62-1.x86_64
Redirecting to /bin/systemctl start atd.service
  Running scriptlet: google-chrome-beta-67.0.3396.62-1.x86_64
  Erasing          : google-chrome-beta-67.0.3396.62-1.x86_64
  Running scriptlet: google-chrome-beta-67.0.3396.62-1.x86_64
  Verifying        : google-chrome-beta-67.0.3396.62-1.x86_64
  Verifying        : google-chrome-beta-67.0.3396.62-1.x86_64

I haven't dug very deep, but I wonder if this can impact the delivery of package updates to users whose installations have proceeded like mine.
 
Maybe we need to defer more work to later via rpmrepo.cron?

Sign in to add a comment