search

coreos / rpm-ostree

⚛📦 Hybrid image/package system with atomic upgrades and package layering
https://coreos.github.io/rpm-ostree
Other
857 stars 193 forks source link

fix libdnf critical #2477

Open cgwalters opened 3 years ago

cgwalters commented 3 years ago

Saw this in https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/pr-logs/pull/openshift_os/490/pull-ci-openshift-os-master-unit/1352626743197831168/artifacts/build-logs/bin.log

(rpm-ostree compose tree:218): libdnf-CRITICAL **: 14:47:04.136: Detection of Platform Module failed: No valid Platform ID detected
cgwalters commented 3 years ago

OK so this seems to be fallout from having an empty install root. I don't quite understand what the PLATFORM_ID value is; should we be setting it? From what? Conceptually this seems like it's duplicating (extending?) $releasever, which we support explicitly specifying in the treefile today.

jlebon commented 3 years ago

When I dug into this recently-ish, what I found out was:

  1. It's a field it looks for in /etc/os-release. That field is in Fedora's /etc/os-release but not RHCOS/RHEL.
  2. It's used for modularity stuff.
  3. There wasn't any obvious way to make it not try to fetch it.
jlebon commented 3 years ago

OK, more info on this now that I grok more of the modularity implementation details.

TL;DR: This will be fixed by #2760.

I don't quite understand what the PLATFORM_ID value is

It's a way for modules to specify what Fedora userspace they're intended for. E.g. here's the module metadata for cri-o:1.20: https://src.fedoraproject.org/modules/cri-o/blob/1.20/f/cri-o.yaml:

dependencies:
    - buildrequires:
          platform: [-f32, -f33, -f34]
      requires:
          platform: [-f32, -f33, -f34]

This means that the 1.20 stream is built three separate times, once for each release buildroot, and each with something akin to a Requires: platform:fNN. PLATFORM_ID is akin to a Provides: platform:fNN which libdnf uses to filter out modules not intended for the system. For Fedora it usually doesn't matter because they're in separate repos anyway, but this breaks down during major version rebases on traditional systems because the current PLATFORM_ID won't match the target one, which leads to...

should we be setting it?

With this patch, it should now be detected auto-magically. If you want more details, see https://bugzilla.redhat.com/show_bug.cgi?id=1688462. We have a small hack in #2760 to deal with how this auto-detection interacts with lockfile repos, but otherwise it works fine.

  1. It's a field it looks for in /etc/os-release. That field is in Fedora's /etc/os-release but not RHCOS/RHEL.

This is incorrect. It's in RHEL but not RHCOS. An internal MR to redhat-release-coreos fixes this.

Conan-Kudo commented 3 years ago

libdnf has an alternative path for installroot: it uses Provides: base-module(platform:$DISTTAG) stanza declared in the release package to determine the base module.

In CentOS Stream 8, this is in centos-release-stream: https://git.centos.org/rpms/centos-stream-release/blob/c8s/f/SPECS/centos-stream-release.spec#_40-42

In Fedora, this is in fedora-release: https://src.fedoraproject.org/rpms/fedora-release/blob/rawhide/f/fedora-release.spec#_93

Conan-Kudo commented 3 years ago

A fuller explanation of this can be seen here: https://git.centos.org/rpms/centos-release/pull-request/6