First, let me apologize for the short notice on this. We've been
discussing it at the public ELN meetings over the last month, but I
only just now realized that I forgot to send out one of these general
announcements.
Over the last few months, you've probably seen a number of Fedora ELN
packages preliminarily imported into Gitlab for CentOS Stream 10 as we
get the machinery working. As of today, we've finally cleared the
remaining blockers to perform the full import of both runtime and
buildroot-only packages.
We are going to trigger a mass-rebuild of those packages included in
Fedora ELN later today in a side-tag, which will likely continue
through the weekend. All of the packages that successfully rebuild
will be automatically imported into CentOS Stream 10 via automation
and we will look into any and all failures over the course of next
week. This mass-rebuild will be performed with "background" priority
in Koji to minimize the impact on other builds, but there is still a
high likelihood that you may have a longer-than-usual waiting time for
your package builds. Fortunately, Fedora ELN is a relatively small
subset of Fedora packages (~2,500 vs Fedora's ~37,000), so it
shouldn't be too bad.
This mass-rebuild will automatically retry failed builds at least once
(to help rule out test-flakes/infra hiccoughs) and possibly numerous
times, since they are all being submitted to the automation as a
single, large batch. Please do not panic if you see your package being
submitted and failing repeatedly. For more information on the rebuild
strategy we use, please see
https://sgallagh.wordpress.com/2023/10/13/sausage-factory-fedora-eln-rebuil…
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Improve support for unified kernels in Fedora.
== Owner ==
* Name: [[User:kraxel| Gerd Hoffmann]]
* Email: kraxel(a)redhat.com
* Name: [[User:vittyvk| Vitaly Kuznetsov]]
* Email: vkuznets(a)redhat.com
== Detailed Description ==
See [[ Changes/Unified_Kernel_Support_Phase_1 ]] for overview and Phase 1 goals.
==== Phase 2 goals ====
* Add support for booting UKIs directly.
** Boot path is shim.efi -> UKI, without any boot loader (grub,
sd-boot) involved.
** The UEFI boot configuration will get an entry for each kernel installed.
** Newly installed kernels are configured to be booted once (via BootNext).
** Successful boot of the system will make the kernel update permanent
(update BootOrder).
* Enable UKIs for aarch64.
** Should be just flipping the switch, dependencies such as kernel
zboot support are merged.
* Add a UEFI-only cloud image variant which uses UKIs.
** Also suitable for being used in confidential VMs.
** Cover both x86_64 and aarch64.
==== Related bugs ====
* shim: remove dependency on grub2-efi-x64
([https://bugzilla.redhat.com/show_bug.cgi?id=2240989 buzilla
2240989])
* shim: handling of multiple lines in BOOT.CSV is inconsistent
([https://issues.redhat.com/browse/RHEL-10704 jira RHEL-10704],
[https://github.com/rhboot/shim/issues/554 github 554])
* anaconda: add support for
[https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
discoverable partitions]
([https://bugzilla.redhat.com/show_bug.cgi?id=2160074 bugzilla
2160074], [https://bugzilla.redhat.com/show_bug.cgi?id=2178043
bugzilla 2178043])
* dracut: do not create yet another initramfs for UKIs
([https://github.com/dracutdevs/dracut/pull/2521 github PR 2521])
* kernel: enable UKIs on aarch64
([https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2818 MR
2818])
== Feedback ==
== Benefit to Fedora ==
* Better secure boot support: the UKI initrd is covered by the signature.
* Better support for tpm measurements and confidential computing.
** measurements are more useful if we know what hashes to expect for the initrd.
** measurements are more useful without grub.efi in the boot path
(which measures each grub.cfg line processed).
* More robust boot process
** generating the initrd on the installed system is fragile
== Scope ==
* Proposal owners:
** updates for virt-firmware and uki-direct packages.
** enable UKIs on aarch64
([https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2818 MR
2818]).
** prepare kickstart ([https://pagure.io/fedora-kickstarts.git Fedora
kickstarts]) changes for generating UKI enabled images.
* Other developers:
** installer/anaconda: implement discoverable partition support.
** bootloader/shim: fix bugs.
** Fedora Cloud SIG: Add UKI enabled images as an option to
[https://fedoraproject.org/cloud/download Download Fedora Cloud]
** See also: [https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_2#Relat…
Related Bugs] section.
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
None, it's opt-in. Also the uefi cloud image is an additional image
and will not replace the current bios/uefi hybrid image.
== How To Test ==
==== Switch an existing install to use UKIs. ====
Needs up-to-date Fedora 39 or Rawhide install in a virtual machine.
Bare metal hardware with standard storage (ahci / nvme) should work too.
Needs an big enough ESP to store UKI images there (minimum 200M,
recommended 500M).
1. dnf install virt-firmware uki-direct
* The uki-direct package contains the kernel-install plugin and
systemd unit needed to automatically manage kernel updates.
* You should have version 23.10 or newer.
2. sh /usr/share/doc/python3-virt-firmware/experimental/fixup-partitions-for-uki.sh
* Workaround for [https://bugzilla.redhat.com/show_bug.cgi?id=2160074
bug 2160074] (anaconda not setting up
[https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
discoverable partitions]).
* UKIs need this to find the root filesystem without root=... on the
kernel command line.
3. dnf install kernel-uki-virt
4. kernel-bootcfg --show
* optional step, shows UEFI boot configuration, the new UKI should be
added as BootNext
$ kernel-bootcfg --show
# C - BootCurrent, N - BootNext, O - BootOrder
# --------------------------------------------
# N - 0008 - 6.5.7-300.fc39.x86_64 <= entry for
the the new kernel
# C O - 0007 - 6.5.6-300.fc39.x86_64 <= currently
running kernel
# O - 0006 - Fedora <= grub2 entry
# O - 0001 - UEFI QEMU QEMU HARDDISK
[ ... ]
5. reboot
6. kernel-bootcfg --show
* optional again, after successful boot the new kernel should be first
in BootOrder.
$ kernel-bootcfg --show
# C - BootCurrent, N - BootNext, O - BootOrder
# --------------------------------------------
# C O - 0008 - 6.5.7-300.fc39.x86_64
# O - 0007 - 6.5.6-300.fc39.x86_64
# O - 0006 - Fedora
# O - 0001 - UEFI QEMU QEMU HARDDISK
[ ... ]
==== Test UKI cloud images ====
Repo with kickstart files and scripts: https://gitlab.com/kraxel/fedora-uki
Images for download: https://www.kraxel.org/fedora-uki/
* fedora-uki-cloud: uki-based cloud image, use cloud-init to configure this.
* fedora-uki-direct: minimal uki-based image, root password is 'root'.
* fedora-classic: minimal non-uki image, root password is 'root'.
Known problems:
* images can fail to boot on the first attempt
** should that happen reset the guest once, the second and all
following boots will work fine.
** root cause is a shim bug
([https://github.com/rhboot/shim/issues/554 github 554]).
** known workaround: add a vTPM to the guest configuration.
==== Booting another kernel ====
From the booted system:
* uefi-boot-menu --reboot
From the firmware:
If your UEFI firmware offers an boot menu you should be able to use
that to select the kernel to boot. Unfortunately this is not
standardized so there is no standard procedure to do so.
* Virtual machines (OVMF): Enter the firmware setup by pressing ESC
when you see the tianocore splash screen. Select "Boot Manager" in
the toplevel menu.
* Thinkpad laptops: Interupt normal boot (just 'Enter' on recent
hardware, or using the special key on older models), then press F12
("choose a temporary startup device").
== User Experience ==
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism:
** drop kickstart file for the uefi-only cloud image.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Hello all,
Fedora Linux 37 has gone end of life for updates and support on 2023-12-05.
No more updates of any kind, including security updates or security
announcements, will be available for Fedora Linux 37 after the said
date. All the updates of Fedora Linux 37 being pushed to stable will be
stopped as well.
Fedora Linux 38 will continue to receive updates until approximately
one month after the release of Fedora Linux 40. The maintenance
schedule of Fedora Linux releases is documented on the Fedora Project
wiki [1]. The Fedora Project wiki also contains instructions[2] on how
to upgrade from a previous release of Fedora Linux to a version
receiving updates.
This email template is also in https://pagure.io/releng if you wish to
propose improvements or changes to it.
Regards,
Tomas Hrcka
Fedora Release Engineering
[1] -
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedu…
[2] - https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades
[3] - https://pagure.io/releng
--
Tomas Hrcka
fas: humaton
libera.CHAT: jednorozec