What is the reason for having microcode_ctl installed in a container in the first place?

> What is the reason for having microcode_ctl installed in a container in the first place?

This is about RHEL CoreOS primarily; we're not installing microcode_ctl in a container there.  As the PR says, the immediate problem is that the RT kernel doesn't have the `Provides: kernel` and so this package is forcing both kernels to be installed, which we don't want.

(The reason I mentioned containers first is just because that's the reason a lot of other Fedora packages dropped requirements on a `kernel` package, including systemd, glibc etc.)

So, for enabling kernel-rt support, more changes are actually needed (like wiring triggers for it, and probably some changes throughout the scripts themselves), and the posttrans transaction is outright incorrect now: it is ought to require dracut and not kernel.

> So, for enabling kernel-rt support, more changes are actually needed (like wiring triggers for it, and probably some changes throughout the scripts themselves), and the posttrans transaction is outright incorrect now: it is ought to require dracut and not kernel.

All of that is unused for rpm-ostree (RHEL CoreOS) based systems.  rpm-ostree disables the microcode_ctl %posttrans entirely.  See:
https://github.com/coreos/rpm-ostree/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aclosed+microcode_ctl

Originally: https://bugzilla.redhat.com/show_bug.cgi?id=1199582

TL;DR As a hybrid image/package system, rpm-ostree generates initramfs images on the *server* side, not client.  It must own the dracut invocation.

If you want to make changes to the %posttrans to help traditional yum-based RHEL systems, that seems fine too of course!  But that's not what's being asked for here.

> and the posttrans transaction is outright incorrect now: it is ought to require dracut and not kernel.

I updated the PR https://src.osci.redhat.com/rpms/microcode_ctl/pull-request/9 to check for `/usr/bin/dracut` instead.

This is an important bug for OpenShift - if it'd help, happy to do a realtime chat to explain things, or whatever else would be helpful!

The desired goal is to the the linked PR merged, then an update built for 8.2.0 as well as 8.1.z that we can tag into the RHCOS 4.3 stream.

Ping?

Currently our work on enabling the RT kernel is carrying a build of microcode_ctl with this patch so work isn't blocked, but it's pulling from my fedorapeople page, which we obviously don't want to ship via that mechanism:

https://github.com/williamcaban/ocp-rt/blob/76fb33553ecd8914d7ccd31ce9e9b46043e563e1/rhcos-rt.sh#L14

If we have to, I guess we can fork this package for RHCOS, but I'd obviously prefer not to, particularly given how simple and small of a patch this is.

(In reply to Colin Walters from comment #5)
> > So, for enabling kernel-rt support, more changes are actually needed (like wiring triggers for it, and probably some changes throughout the scripts themselves), and the posttrans transaction is outright incorrect now: it is ought to require dracut and not kernel.
> 
> All of that is unused for rpm-ostree (RHEL CoreOS) based systems. 
> rpm-ostree disables the microcode_ctl %posttrans entirely.  See:
> https://github.com/coreos/rpm-ostree/
> pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aclosed+microcode_ctl

By the way, why rpm-ostree honours "Requires(posttrans)" if it ignores the script itself? That seems illogical and inconsistent.

> By the way, why rpm-ostree honours "Requires(posttrans)" if it ignores the script itself? That seems illogical and inconsistent.

Basically because:

1) It wasn't necessary to override
2) Implementing such a thing would require *deep* hooks into libdnf and the underlying libsolv layer, I suspect it'd need new API.  Or, we'd need to edit the RPM headers before we passed it down to libdnf.

We already pull in `dracut` anyways, so the status quo is fine by me.

While we're discussing this, can you (or someone) remind me why the Fedora and RHEL microcode_ctl packages have diverged so much?

There's no %posttrans today in
https://src.fedoraproject.org/rpms/microcode_ctl/blob/master/f/microcode_ctl.spec
We basically just rely on the early microcode bits being pulled in by dracut.  Why should (classic yum based) RHEL be any different?

(In reply to Colin Walters from comment #19)
> While we're discussing this, can you (or someone) remind me why the Fedora
> and RHEL microcode_ctl packages have diverged so much?

It's mostly (1) because RHEL package has to cater for RHEL-specific/RHEL-sensitive issues (see bugs 1398698, 1596627, 1646383, 1758382, for example), and (2) because microcode_ctl binary itself is mostly irrelevant with Intel's move from monolithic microcode.dat format to per-model ucode files. I should work on taking the ownership of the Fedora package and sync it up before the RHEL 9 branching, but it hasn't happened yet.

> There's no %posttrans today in
> https://src.fedoraproject.org/rpms/microcode_ctl/blob/master/f/microcode_ctl.
> spec
> We basically just rely on the early microcode bits being pulled in by
> dracut.  Why should (classic yum based) RHEL be any different?

The %posttrans script, specifically, is a result of addressing bugs 1151192, 1292158 and 1398698.

OK, https://bugzilla.redhat.com/show_bug.cgi?id=1151192 isn't an issue for rpm-ostree based systems as we always generate a new initramfs server side on any change.

I guess with Fedora kernel updates are pretty common - more frequent that microcode releases, but that may be different for RHEL.
 
https://bugzilla.redhat.com/show_bug.cgi?id=1292158 is actually more *caused* by the posttrans, not fixed by it AFAICS.  Anaconda has code to regenerate the initramfs on the target system for yum-based systems (that's what yum-based Fedora editions like Workstation/Server rely on today AFAIK).

And https://bugzilla.redhat.com/show_bug.cgi?id=1398698 is obviously one of many "system interrupted during upgrade" issues that rpm-ostree categorically fixes.

> I should work on taking the ownership of the Fedora package and sync it up before the RHEL 9 branching, but it hasn't happened yet.

That'd be great!  It would really help I think to have this stuff land in Fedora *first* (it will hence be tested by rpm-ostree based editions like Fedora CoreOS, IoT and Silverblue) first.

I guess we might as well be consistent and have the %posttrans in the Fedora package as well.

(In reply to Colin Walters from comment #21)

Hm, was the change in bug status intentional?

(In reply to Colin Walters from comment #21)
> I guess with Fedora kernel updates are pretty common - more frequent that
> microcode releases, but that may be different for RHEL.

It's not about frequency, it's about delivering the latest microcode to mitigate the arising CPU microarchitecture issues (which is the main reason of microcode updates now).

> https://bugzilla.redhat.com/show_bug.cgi?id=1292158 is actually more
> *caused* by the posttrans, not fixed by it AFAICS.  Anaconda has code to
> regenerate the initramfs on the target system for yum-based systems (that's
> what yum-based Fedora editions like Workstation/Server rely on today AFAIK).

Yes, it does, but it won't help with microcode_ctl package update.

Verified with microcode_ctl-20191115-4.el8.

Note: kernel-rt packages in RHEL-8.2.0 have a "Provides: kernel" now, so trying to replace kernel with kernel-rt is no longer a sufficient test.  But a quick check of microcode_ctl's requirements show that kernel is indeed dropped, and dracut is required instead.

::::::::::::
:: Before ::
::::::::::::

[root@lenovo-sr650-01 ~]# rpm -q microcode_ctl
microcode_ctl-20190618-1.el8.x86_64

[root@lenovo-sr650-01 ~]# rpm -q --requires microcode_ctl | grep -e kernel -e dracut
kernel

[root@lenovo-sr650-01 ~]# 


:::::::::::
:: After ::
:::::::::::

[root@lenovo-sr650-01 ~]# rpm -q microcode_ctl
microcode_ctl-20191115-4.el8.x86_64

[root@lenovo-sr650-01 ~]# rpm -q --requires microcode_ctl | grep -e kernel -e dracut
dracut

[root@lenovo-sr650-01 ~]#

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:1761