See https://github.com/coreos/rpm-ostree/pull/2330
and https://bugzilla.redhat.com/show_bug.cgi?id=1742764

Essentially what nvme-cli is doing with e.g.

uuidgen > %{_sysconfdir}/nvme/hostid

is wrong for rpm-ostree (or really, any image update system). That value will be encoded into the base image, not set per instance. Instead, you need to use a systemd unit for this.

However, this value duplicates `/etc/machine-id` that is managed by systemd. Do you really need a separate one at all? If you do, see
https://www.freedesktop.org/software/systemd/man/machine-id.html

> This ID uniquely identifies the host. It should be considered "confidential", and must not be exposed in untrusted environments, in particular on the network. If a stable unique identifier that is tied to the machine is needed for some application, the machine ID or any part of it must not be used directly. Instead the machine ID should be hashed with a cryptographic, keyed hash function, using a fixed, application-specific key. That way the ID will be properly unique, and derived in a constant way from the machine ID but there will be no way to retrieve the original machine ID from the application-specific one. The sd_id128_get_machine_app_specific(3) API provides an implementation of such an algorithm.

—

It looks like the current Fedora package doesn't do this, so one option is synchronizing to the current state of that package.