Cross-filed case #03403434 at the Red Hat customer portal.

Thank you Robert for bringing up this issue. It's a good idea, and it makes sense.

We will propose this change to the upstream (Fedora) first. If it is not accepted, we will make this change RHEL only.

(In reply to Jan Macku from comment #2)
> We will propose this change to the upstream (Fedora) first. If it is not accepted, we will make this change RHEL only.

I'm not really sure how this proposal makes sense. Fedora builds and maintains an up-to-date systemd-boot as part of the regular systemd packages (which RHEL is not doing and most likely won't do, given Red Hat usually only cares about the few less specific (systemd-boot) pieces that are actually needed for RHEL). So this is IMHO already RHEL-only, or am I wrong?

(In reply to Robert Scheck from comment #3)
> (In reply to Jan Macku from comment #2)
> > We will propose this change to the upstream (Fedora) first. If it is not accepted, we will make this change RHEL only.
> 
> I'm not really sure how this proposal makes sense. Fedora builds and
> maintains an up-to-date systemd-boot as part of the regular systemd packages
> (which RHEL is not doing and most likely won't do, given Red Hat usually
> only cares about the few less specific (systemd-boot) pieces that are
> actually needed for RHEL). So this is IMHO already RHEL-only, or am I wrong?

It makes sense because Fedora is RHEL's upstream, and having those changes upstreamed into the Fedora systemd package makes it easier for them to not accidentally drop it later when they do future rebases. Moreover, Fedora ELN is RHEL's future, so having those details captured there makes it much easier to continuously maintain these package splits and take care to not mess up the content sets in the future.

Well, when I thought last time that it could make sense to split off a package in Fedora to ease my work in EPEL, I ended up like as in bug #1887169.

Jan: Did you already propose the change as mentioned in comment #2? And if so, is there any public tracking ID for it?

We are planning to make this change in 9.2. There is no Fedora tracker related to this issue, but we have discussed it with Zbigniew.

There is already a subpackage in Fedora called boot-unsigned[1], but it doesn't contain all systemd-boot related stuff. We have another meeting planned where we will discuss it.

[1] - https://src.fedoraproject.org/rpms/systemd/c/54a3b6f942abf61353782847df11012338157285

Robert, are you planning to update systemd-extras to 252 now that this is finished? I'm suddenly finding myself without access to systemd-boot in C9S.

Daan, yes.

However, Jan, is it really intended that the following files are still shipped by systemd in CentOS Stream 9? I would have expected that these files are either moved into te boot subpackage - or simply just removed.

file /usr/share/man/man7/systemd-stub.7.gz from install of systemd-boot-250.3-1.el9.x86_64 conflicts with file from package systemd-252-8.el9.x86_64
file /usr/bin/bootctl from install of systemd-boot-250.3-1.el9.x86_64 conflicts with file from package systemd-udev-252-8.el9.x86_64
file /usr/lib/systemd/system-generators/systemd-bless-boot-generator from install of systemd-boot-250.3-1.el9.x86_64 conflicts with file from package systemd-udev-252-8.el9.x86_64
file /usr/lib/systemd/system/systemd-boot-system-token.service from install of systemd-boot-250.3-1.el9.x86_64 conflicts with file from package systemd-udev-252-8.el9.x86_64
file /usr/lib/systemd/systemd-bless-boot from install of systemd-boot-250.3-1.el9.x86_64 conflicts with file from package systemd-udev-252-8.el9.x86_64
file /usr/share/bash-completion/completions/bootctl from install of systemd-boot-250.3-1.el9.x86_64 conflicts with file from package systemd-udev-252-8.el9.x86_64
file /usr/share/man/man1/bootctl.1.gz from install of systemd-boot-250.3-1.el9.x86_64 conflicts with file from package systemd-udev-252-8.el9.x86_64
file /usr/share/man/man5/loader.conf.5.gz from install of systemd-boot-250.3-1.el9.x86_64 conflicts with file from package systemd-udev-252-8.el9.x86_64
file /usr/share/man/man7/systemd-boot.7.gz from install of systemd-boot-250.3-1.el9.x86_64 conflicts with file from package systemd-udev-252-8.el9.x86_64
file /usr/share/man/man8/systemd-bless-boot-generator.8.gz from install of systemd-boot-250.3-1.el9.x86_64 conflicts with file from package systemd-udev-252-8.el9.x86_64
file /usr/share/man/man8/systemd-bless-boot.service.8.gz from install of systemd-boot-250.3-1.el9.x86_64 conflicts with file from package systemd-udev-252-8.el9.x86_64
file /usr/share/man/man8/systemd-boot-system-token.service.8.gz from install of systemd-boot-250.3-1.el9.x86_64 conflicts with file from package systemd-udev-252-8.el9.x86_64
file /usr/share/zsh/site-functions/_bootctl from install of systemd-boot-250.3-1.el9.x86_64 conflicts with file from package systemd-udev-252-8.el9.x86_64

I thought Red Hat only cares about the systemd-boot EFI stubs, so the rest shouldn't be shipped at all, right? Otherwise this doesn't make much sense to me.

/usr/share/man/man8/systemd-boot-check-no-failures.8.gz
/usr/share/man/man8/systemd-boot-check-no-failures.service.8.gz
/usr/lib/systemd/system/systemd-boot-check-no-failures.service
/usr/lib/systemd/systemd-boot-check-no-failures

might additionally also be related to systemd-boot, but shipped by systemd in CentOS Stream 9, too.

Oh, and /usr/share/man/man7/sd-boot.7.gz as well (which is part of systemd-boot-unsigned at Fedora, but not at CentOS Stream 9).

Yes, we are missing the following commit from Fedora:

Move man pages for sd-boot into systemd-boot-unsigned - https://src.fedoraproject.org/rpms/systemd/c/7a81930dd22098eca6c21ffd0732db8b1d3743a0?branch=rawhide

(In reply to Jan Macku from comment #37)
> Yes, we are missing the following commit from Fedora:
> 
> Move man pages for sd-boot into systemd-boot-unsigned -
> https://src.fedoraproject.org/rpms/systemd/c/
> 7a81930dd22098eca6c21ffd0732db8b1d3743a0?branch=rawhide

But it's not just man pages. So the mentioned commit doesn't answer all of comment #34, #35 and #36.

And Fedora commit:

Move /usr/lib/systemd/boot/ to systemd-boot-unsigned subpackage - https://src.fedoraproject.org/rpms/systemd/c/1a6178ce6eb7f9e289db01519ca510ad77760e83?branch=rawhide

The rest of the "boot" related files will stay in the systemd-udev package since they might be useful for other system components.

/usr/bin/bootctl
/usr/lib/systemd/system-generators/systemd-bless-boot-generator
/usr/lib/systemd/system/sysinit.target.wants/systemd-boot-system-token.service
/usr/lib/systemd/system/systemd-bless-boot.service
/usr/lib/systemd/system/systemd-boot-system-token.service
/usr/lib/systemd/system/systemd-boot-update.service
/usr/lib/systemd/systemd-bless-boot
/usr/share/bash-completion/completions/bootctl
/usr/share/man/man1/bootctl.1.gz
/usr/share/man/man7/sd-boot.7.gz
/usr/share/man/man7/systemd-boot.7.gz
/usr/share/man/man8/systemd-bless-boot-generator.8.gz
/usr/share/man/man8/systemd-bless-boot.8.gz
/usr/share/man/man8/systemd-bless-boot.service.8.gz
/usr/share/man/man8/systemd-boot-system-token.service.8.gz
/usr/share/zsh/site-functions/_bootctl

Do I get it correctly, that the files in your list in comment #39 will stay in systemd-udev, then? If so, this conflicts with my initial request - because it leads to the unfortunate situation that Red Hat then uses more than just the systemd-boot EFI stub. Or sloppily summarized: This leaves me with a crippled systemd-boot, because only some parts of systemd-boot are moved to separate buildroot-only subpackage.

I would like to see the following: Either a full systemd-boot in RHEL 9 directly (maintained by Red Hat) - or not at all (= all systemd-boot related files in a to separate buildroot-only subpackage). Before bug #2140646 there was no systemd-boot in RHEL 9 at all, which enabled me to ship a full systemd-boot via EPEL 9. Then bug #2140646 happened, which (from my understanding) shall use only the systemd-boot EFI stub to achieve "Azure Confidential VMs" (= RHEL kernel + pre-generated initrd + systemd-boot EFI stub), however without using the systemd-boot UEFI boot manager for the actual EFI boot process, correct?

And if so, why do now the other parts of systemd-boot need to be shipped by RHEL 9 then? How would "bootctl", "systemd-boot-update.service", "systemd-boot-system-token.service" be useful when not using systemd-boot UEFI boot manager for the actual EFI boot process? For me, my request, the move of systemd-boot related files to a separate buildroot-only subpackage, makes only sense if really no parts of systemd-boot end up in a RHEL 9 non-buildroot-only package.

bootctl can be useful without systemd-boot and the bless-boot stuff is not systemd-boot specific, but can be useful for any boot loader implementing the boot loader specification. I'm not sure why a full systemd-boot needs to be shipped in EPEL 9? We just need to ship the files that are not in C9S (specifically the systemd-udev) package? Unless you're planning to ship newer versions of systemd-boot than the version of systemd in C9S itself. Given that the version in C9S is already extremely recent, I don't think there's a huge need to ship newer versions of systemd-boot.

I have already merged recent Fedora split-files changes to c9s (man pages and /usr/lib/systemd/boot/) will be in boot-unsigned.

The rest of the files will stay in udev package to stay synced with the Fedora packaging. Also, as Daan mentioned, they could be used beyond systemd-boot.

I'm planning to do a build of c9s next week.

(In reply to Daan De Meyer from comment #41)
> Unless you're planning to ship newer versions of systemd-boot than the version of systemd in C9S itself.

I not only plan this, I already did this - until the last systemd rebase in C9S. And I would like to continue with this (I do similar for systemd-networkd for some years quite successfully now, see EPEL 8 as specific example).

> Given that the version in C9S is already extremely recent, I don't think there's a huge need to ship newer versions of systemd-boot.

This is the difference between us: I would like to see future features of systemd-boot available for RHEL 9 - also at a point where Red Hat refuses rebases or large backports (which is quite likely from my past experiences in about 1-2 years, but at latest when C9S reaches EOL).

> We just need to ship the files that are not in C9S (specifically the systemd-udev) package?

No, because systemd-extras is currently tracking Fedora, not C9S. Enough users care about an up-to-date systemd-networkd (and systemd-timesyncd).


(In reply to Jan Macku from comment #42)
> The rest of the files will stay in udev package to stay synced with the Fedora packaging. Also, as Daan mentioned, they could be used beyond
> systemd-boot.

Given Red Hat makes me hereby unable to ship an up-to-date systemd-boot in EPEL 9, would shipping *all* systemd-boot related files in non-buildroot-only packages in RHEL 9 be an option? A sooner or later stale systemd-boot (as explained above) might be better on the long term for users than maybe breaking systemd-boot by combining more recent EFI stubs with outdated tools/services.

Any timeline for the new systemd release? C9S support in mkosi has been broken for quite a while now because of this change, I'd like to get it working again.

Jan, may I kindly ask you for a comment related to my comment #43, especially to the very last part? Thank you :)

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 (systemd 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/RHBA-2023:2531

Hi Robert,
I'm sorry I didn't make it clear. We don't plan to ship or support systemd-boot in RHEL9. This may change in future RHEL major versions, but for now, grub is the only supported option.

Thank you, Red Hat, for crippling systemd-boot with RHEL 9.2 ;-(