Bug 2184476

(In reply to Peter Georg from comment #0)
> Description of problem:
> kernel-uki-virt does not list any provides for built-in symbols.
> kernel-uki-virt should list these provides just as kernel-core does. These
> provides are (afaik) generated from modules.builtin which is included in
> kernel-core.

Can you elaborate on why you think this is needed?

UKI isn't a general purpose kernel that we'd expect anyone to build modules against.  It's a self-contained, fully signed kernel used for a very specific usecase.

(In reply to Josh Boyer from comment #2)
> Can you elaborate on why you think this is needed?
> 
> UKI isn't a general purpose kernel that we'd expect anyone to build modules
> against.  It's a self-contained, fully signed kernel used for a very
> specific usecase.

I thought the kernel is the same but just distributed in a different format?
I.e., all kernel modules built against the RHEL kernel should be loadable independently of whether one uses the unified kernel image or the "regular" one. So the question is not about building against a kernel, but about whether one can use third party kernel modules when using the universal kernel image without having to install the regular one in addition.

If you do not expect anyone who is using the unified kernel image to install any third party kernel modules then these provides are not required and you can close this bug report.

(In reply to Peter Georg from comment #3)
> (In reply to Josh Boyer from comment #2)
> > Can you elaborate on why you think this is needed?
> > 
> > UKI isn't a general purpose kernel that we'd expect anyone to build modules
> > against.  It's a self-contained, fully signed kernel used for a very
> > specific usecase.
> 
> I thought the kernel is the same but just distributed in a different format?
> I.e., all kernel modules built against the RHEL kernel should be loadable
> independently of whether one uses the unified kernel image or the "regular"
> one. So the question is not about building against a kernel, but about
> whether one can use third party kernel modules when using the universal
> kernel image without having to install the regular one in addition.
> 
> If you do not expect anyone who is using the unified kernel image to install
> any third party kernel modules then these provides are not required and you
> can close this bug report.

Generally speaking your suggestion is correct and there is no reason to not support
third party modules when UKI is used instead of the standard kernel-core. As we are
in the very beginning on the adoption path, we wanted to limit UKI's use case to
virtual machines (and thus 'kernel-uki-virt' name) where third party modules are less
common.

Let me take the BZ and run some experiments.

I've created an MR for Fedora/ARK: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2408
if things go well, we can do a similar change to RHEL.

(In reply to Vitaly Kuznetsov from comment #5)
> I've created an MR for Fedora/ARK:
> https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2408
> if things go well, we can do a similar change to RHEL.

The change was merged in Fedora/ARK some time ago and no issues were reported,
pushing the change to RHEL as well.

# rpm -q --provides kernel-uki-virt-5.14.0-330.2721_908379996.el9.x86_64.rpm > uki-provides
# rpm -q --provides kernel-core-5.14.0-330.2721_908379996.el9.x86_64.rpm > core-provides
# diff -u core-provides uki-provides 
--- core-provides	2023-06-25 23:39:12.065892900 -0400
+++ uki-provides	2023-06-25 23:39:04.115430600 -0400
@@ -1,5 +1,4 @@
 installonlypkg(kernel)
-kernel = 5.14.0-330.2721_908379996.el9
 kernel(IO_APIC_get_PCI_irq_vector) = 0x1eb922a3
 kernel(I_BDEV) = 0xb99ad7c5
 kernel(LZ4_decompress_fast) = 0x4c416eb9
@@ -11163,11 +11162,9 @@
 kernel(zstd_init_dstream) = 0x3cbb940b
 kernel(zstd_is_error) = 0xafc6c68e
 kernel(zstd_reset_dstream) = 0xf1a65f7b
-kernel-core = 5.14.0-330.2721_908379996.el9
-kernel-core(x86-64) = 5.14.0-330.2721_908379996.el9
-kernel-core-uname-r = 5.14.0-330.2721_908379996.el9.x86_64
+kernel-uki-virt = 5.14.0-330.2721_908379996.el9
+kernel-uki-virt(x86-64) = 5.14.0-330.2721_908379996.el9
 kernel-uname-r = 5.14.0-330.2721_908379996.el9.x86_64
-kernel-x86_64 = 5.14.0-330.2721_908379996.el9
 kmod(8250.ko)
 kmod(8250_base.ko)
 kmod(8250_dw.ko)
# rpm -ql kernel-uki-virt-5.14.0-330.2721_908379996.el9.x86_64.rpm | grep System.map
/lib/modules/5.14.0-330.2721_908379996.el9.x86_64/System.map

Tested good on 5.14.0-330.2721_908379996.el9.x86_64.
For a comparison:

# rpm -q --provides kernel-uki-virt-5.14.0-330.el9.x86_64.rpm
installonlypkg(kernel)
kernel-uki-virt = 5.14.0-330.el9
kernel-uki-virt(x86-64) = 5.14.0-330.el9
kernel-uname-r = 5.14.0-330.el9.x86_64

# rpm -q --provides kernel-uki-virt-5.14.0-333.el9.x86_64.rpm > uki-provides
# rpm -q --provides kernel-core-5.14.0-333.el9.x86_64.rpm > core-provides
# diff -u core-provides uki-provides
--- core-provides	2023-07-03 04:19:26.491157525 -0400
+++ uki-provides	2023-07-03 04:16:50.714236417 -0400
@@ -1,5 +1,4 @@
 installonlypkg(kernel)
-kernel = 5.14.0-333.el9
 kernel(IO_APIC_get_PCI_irq_vector) = 0x1eb922a3
 kernel(I_BDEV) = 0xbe821159
 kernel(LZ4_decompress_fast) = 0x4c416eb9
@@ -11176,11 +11175,9 @@
 kernel(zstd_init_dstream) = 0x3cbb940b
 kernel(zstd_is_error) = 0xafc6c68e
 kernel(zstd_reset_dstream) = 0xf1a65f7b
-kernel-core = 5.14.0-333.el9
-kernel-core(x86-64) = 5.14.0-333.el9
-kernel-core-uname-r = 5.14.0-333.el9.x86_64
+kernel-uki-virt = 5.14.0-333.el9
+kernel-uki-virt(x86-64) = 5.14.0-333.el9
 kernel-uname-r = 5.14.0-333.el9.x86_64
-kernel-x86_64 = 5.14.0-333.el9
 kmod(8250.ko)
 kmod(8250_base.ko)
 kmod(8250_dw.ko)

Tested good on 5.14.0-333.el9.x86_64.

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 (Important: kernel security, bug fix, and enhancement update), 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/RHSA-2023:6583