U-Boot for x86 BIOS systems
by Neal Gompa
Hey all,
I was chatting with Marcin Juszkiewicz about U-Boot on ARM wrt its
"generic UEFI boot" feature where it can execute UEFI applications. We
use this capability for Fedora on ARM platforms to go from the utterly
barebones and weird initialization processes for various boards to a
UEFI-like environment so we can boot Fedora somewhat normally.
It occurred to me during that conversation that it might be possible
to use this to simplify what we need to care about for x86 too. Last
year, the Red Hat Bootloader team wanted to start a deprecation
process for BIOS[1] and the Fedora Cloud WG has been interested in it
for longer[2].
At least from the Cloud WG side, it's been determined that completely
removing BIOS support is functionally impossible for the next few
years because of AWS and smaller cloud providers not universally
supporting UEFI (and we are still trying to convince them to change
their minds on this...). And I still have plenty of hardware with
broken UEFI implementations that require CSM boot to support Linux.
But could we use U-Boot to fill in this gap so these systems still
work? We'd then treat x86 like ARM (if no UEFI, use U-Boot UEFI).
[1]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
[2]: https://pagure.io/cloud-sig/issue/345
--
真実はいつも一つ！/ Always, there's only one truth!
11 months, 3 weeks
SecureBoot certificates
by Steve Grubb
Hello,
I was poking around a F38 system to look over the Secure Boot certificates and
found something that may warrant attention.
sbattach --detach signature /boot/efi/EFI/BOOT/fbx64.efi
openssl pkcs7 -inform DER -in signature -text -print_certs > grub-certs.txt
Issuer: CN=Fedora Secure Boot CA
Validity
Not Before: Dec 7 16:04:24 2012 GMT
Not After : Dec 5 16:04:24 2022 GMT
Subject: CN=Fedora Secure Boot Signer
Not after Dec 5, 2022 ??? I think this is expired. But also
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
I think we should be on 3072 or higher at this point. But what about the
shim?
sbattach --detach signature /boot/efi/EFI/BOOT/BOOTX64.EFI
openssl pkcs7 -inform DER -in signature -text -print_certs > shim-certs.txt
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
CN=Microsoft Corporation UEFI CA 2011
Validity
Not Before: Sep 9 19:40:20 2021 GMT
Not After : Sep 1 19:40:20 2022 GMT
This is also expired.
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
And also not big enough. This raises a questions. Has Microsoft updated their
certificate? Is it well distributed such that switching to it will not brick
systems? Should Fedora get a new shim for Fedora 39? Can the update move to
3072 to be compliant with CNSA 1.0 requirements? And if so, that also means
moving to SHA-384. Or did I miss some system-upgrade step that updates the
bootloader?
TBH, I am surprised by this finding. But we're all busy and it *is* working.
Best,
-Steve
11 months, 3 weeks
F39 Change Proposal: Automatic Cloud Reboot on Updates
(Self-Contained Change)
by Aoife Moloney
https://fedoraproject.org/wiki/Changes/Automatic_Cloud_Reboot_On_Updates
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 ==
Cloud users can provide cloud-init metadata when creating a Fedora
cloud instance and that metadata can contain instructions to update
all packages on the system and reboot the system if any of those
updated packages need a reboot to go into effect. Fedora cloud
instances should write the `/var/run/reboot-required` file if a reboot
is needed after a dnf update so that cloud-init can reboot the
instance.
This issue originally surfaced in
[https://bugzilla.redhat.com/show_bug.cgi?id=1275409 RHBZ 1275409].
== Owner ==
* Name: [[User:mhayden| Major Hayden]]
* Email: major(a)redhat.com
== Detailed Description ==
Fedora cloud instances use cloud-init to do the initial configuration
of the instance. This includes setting up networking, assigning a
hostname, adding users/groups, and arbitrary scripts. There are also
two options that you can pass to cloud-init that are important for
this change:
* `package_update`: If set to `true`, all installed packages are
immediately updated on first boot
* `package_reboot_if_required`: If set to `true`, and the
`package_update` step wrote to `/var/run/reboot-required`, reboot the
system immediately after updating packages
📚 For more details, see cloud-init's module reference for
`[https://cloudinit.readthedocs.io/en/latest/reference/modules.html#package-update-upgrade-install
package_update]`.
🚨 '''WAIT A MOMENT. ARE WE TALKING ABOUT REBOOTING EVERY CLOUD
INSTANCE ON BOOT?''' 🚨 No! This change would require all three of
these things to happen before a reboot occurs:
* User provides `package_update: true` on instance creation
* '''AND''' user provides `package_reboot_if_required: true` on
instance creation
* '''AND''' `tracer` notices that at least one of the packages need a
reboot to go into effect
🤔 '''Where does this `/var/run/reboot-required` file come from?''' On
Debian and Ubuntu systems, `apt` automatically writes to
`/var/run/reboot-required` if a reboot is needed after a package
update. From there, `cloud-init` looks for the file
([https://github.com/canonical/cloud-init/blob/6d09df5e4786a2a6c79d6098ab41...
relevant cloud-init code]) and if present, reboots the system
immediately.
✏️ '''How do we write this file on Fedora?''' Fedora systems have a
package called `tracer` and a corresponding dnf plugin,
`python3-dnf-plugin-tracer`, that analyzes `dnf` updates and provides
recommendations on reboots or user logouts to bring updates into
effect on the system. A recent
[https://github.com/FrostyX/tracer/pull/196 pull request] added
support for writing the `/var/run/reboot-required` file when a system
reboot is recommended. The `cloud-init` tool can read this file after
a package update and reboot if needed.
🔎 '''What does `tracer`'s output look like?'''
[root@tracer-testing ~]# tracer
You should restart:
* Some applications using:
sudo systemctl restart NetworkManager
sudo systemctl restart auditd
sudo systemctl restart chronyd
sudo systemctl restart dbus-broker
sudo systemctl restart qemu-guest-agent
sudo systemctl restart sshd
sudo systemctl restart systemd-journald
sudo systemctl restart systemd-logind
sudo systemctl restart systemd-oomd
sudo systemctl restart systemd-resolved
sudo systemctl restart systemd-udevd
sudo systemctl restart systemd-userdbd
* These applications manually:
(sd-pam)
Additionally, there are:
- 3 processes requiring restart of your session (i.e. Logging out
& Logging in again)
- 1 processes requiring reboot
[root@tracer-testing ~]# cat /var/run/reboot-required
Tracer says reboot is required
📋 '''What do we need to do?''' Add the `python3-dnf-plugin-tracer`
plugin to Fedora cloud images. No additional configuration is
necessary. This action pulls in five packages that are about 2.1MB
after installation:
=======================================================================================
Package Arch Version
Repository Size
=======================================================================================
Installing:
python3-dnf-plugin-tracer noarch 4.1.0-1.fc38
fedora 14 k
Installing dependencies:
python3-dnf-plugins-extras-common noarch 4.1.0-1.fc38
fedora 69 k
python3-psutil x86_64 5.9.2-2.fc38
fedora 271 k
python3-tracer noarch 0.7.8-5.fc38
fedora 172 k
tracer-common noarch 0.7.8-5.fc38
fedora 22 k
Transaction Summary
=======================================================================================
Install 5 Packages
Total download size: 547 k
Installed size: 2.1 M
== Feedback ==
One of the other ideas was to patch `cloud-init` to run `tracer`
directly and avoid the `/var/run/reboot-required` file altogether.
That would require a lot of work upstream in `cloud-init` to enable
the functionality and we would still need the same set of packages
installed in Fedora anyway. 🥵
== Benefit to Fedora ==
This change allows Fedora cloud instances to behave in the same way
that Debian-based instances already behave. When users request package
updates with a reboot now, `cloud-init` performs the update but never
reboots the system. This is an unexpected and confusing result for
users who come to Fedora from other distributions.
Rebooting automatically could also reduce the attack surface of an
instance that just came online since it would immediately reboot to
put all package updates into effect on the system. This reduces the
time that an unpatched instance is online prior to being fully
patched.
== Scope ==
* Proposal owners: This change is fairly isolated and only affects
Fedora cloud users who request package updates followed by a reboot in
their `cloud-init` metadata.
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with Community Initiatives: N/A
== Upgrade/compatibility impact ==
Since this change only applies to `cloud-init` on the very first boot
of the instance, this wouldn't affect a user upgrading from one
version of Fedora to the next.
== How To Test ==
# Ensure you have a cloud image that has an update that needs a reboot
(kernel, openssl, etc)
# Boot an instance with the following `cloud-init` user data:
#cloud-config
package_update: true
package_upgrade: true
package_reboot_if_required: true
# Wait for the package updates to finish on the instance and verify
that it rebooted after updating
== User Experience ==
First, if a user never uses the `package_upgrade` and
`package_reboot_if_required` options in their `cloud-init` user data,
they won't be affected by this change. These options are not enabled
in `cloud-init` by default.
If a user does enable both of these options, they will see their cloud
instance come online, apply updates, and reboot if required. Most
cloud providers have very fast reboots, so the delay should not be a
problem.
== Dependencies ==
Nothing depends on this change.
== Contingency Plan ==
* Contingency mechanism: Push to Fedora 40 if the work cannot be done in time
* Contingency deadline: N/A
* Blocks release? N/A
== Documentation ==
Guidance for users in a blog post (Fedora Magazine) could be helpful
for this change. Many users might not be aware that they had the
option to ask for package updates and reboots via `cloud-init` for
their Fedora cloud instances.
== Release Notes ==
Fedora cloud instances now automatically reboot when a user requests
package updates followed by a reboot on the first boot of the
instance. The reboot only occurs if an updated package requires a
reboot to go into effect (such as a kernel or critical system
library).
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
11 months, 3 weeks
RISC-V -- are we ready for more, and what do we need to do it?
by Matthew Miller
Hi all! I just got back from Open Source Summit, several of the talks I
found interesting were on RISC-V -- a high-level one about the
organizational structure, and Drew Fustini's more technical talk.
In that, he noted that there's a Fedora build *, but it isn't an official
Fedora arch. As I understand it, the major infrastructure blocker is simply
that there isn't server-class hardware (let alone hardware that will build
fast enough that it isn't a frustrating bottleneck).
So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances
as builders, could we build fast enough under QEMU emulation to work? We
have a nice early advantage, but if we don't keep moving, we'll lose that.
But beyond that: What other things might be limits? Are there key bits of
the distro which don't build yet? Is there a big enough risc-v team to
respond to arch-specific build failures? And, do we have enough people to do
QA around release time?
* see http://fedora.riscv.rocks/koji/
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
11 months, 3 weeks
F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)
by Aoife Moloney
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 ==
This is the last step in
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
effort. Jdks in fedora are already static, and we repack portable
tarball into rpms. Currently, the portbale tarball is built for each
Fedora and Epel version. Goal here is to build each jdk
(8,11,17,21,latest (20)) only once, in oldest live Fedora xor Epel and
repack in all live fedoras.
== Owner ==
* Name: [[User:jvanek| Jiri Vanek]]
* Email: jvanek(a)redhat.com
== Detailed Description ==
As described in
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ;
during last year, packaging of JDKs had changed dramatically. As
described in same wiki page, and individual sub changes and devel
threads, with primary reason this - to lower maintenance and still
keep fedora java friendly.
* In first system wide change, we had changed JDKs to build properly
as standalone, portable jdk - the wey JDK is supposed to be built. I
repeat, we spent ten years by patching JDK to become properly dynamic
against system libs, and all patches went usptream, but it become
fight which can not be win
* as a second step we introduced portable rpms, which do not have any
system integration, only builds JDK and pack final tarball in RPM for
free use.
* In third step - without any noise, just verified with fesco -
https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully
integrated rpms. Instead of this, normal RPMS BUildRequire portable
rpms and just unpack it, and repack it.
Now last step is ahead - to build portable LTS JDKs 8,11,17 and 21 in
oldest live Fedora, and repack everywhere. java-latest-openjdk, which
contains latest STS jdk - currently 20, soon briefly 21 and a bit
alter 22... Should be built in latest live EPEL - epel8 now. We have
verified, that such repacked JDKs work fine.
== Feedback ==
== Benefit to Fedora ==
java maintainers will finally some free time... No kidding -
maintenance and *certification* of so much supported JDKs on so much
Fedora versions is brutal. By building once, and repack, we will
regain cycles to continue support Fedora with all LTS and one STS
javas.
If we fail to build once and repack everywhere, java maintainers will
most likely need to lower the number of JDKs in fedora to system one
only.
== Scope ==
* Proposal owners: Technically all jdks (except 8, where some more
tuning is needed, and epels for java-latest) are prepared, as they
have portable version, and rpms just reapck it. Except tuning up the
jdk8 and epel for latest, scope owners are done.
* Other developers: There will be needed significant support from RCM
and maybe senior fedora leadership to help to finish the build in
oldest and enable to repack everywhere<!--
* '''Release engineering: [https://pagure.io/releng/issue/11438
#11438]''' There will be needed significant support from RCM, where
I'm actually unsure what they will have to do to enable this. The mas
rebuild will not be needed.
* Policies and guidelines: AFAIK none (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: All supported JDKS will remain
in Fedora in highest possible quality with full QA and certification,
and its packagers will not lose their minds. note, that QA will still
run on all live fedoras, not only on the builder one.
== Upgrade/compatibility impact ==
The change should be completely transparent to any user.
== How To Test ==
`sudo dnf update/install "java*"` will install expected set of working packages.
== User Experience ==
The change should be absolutely transparent to any user.
== Dependencies ==
To finish this we will need heavy support from RCM, and maybe others.
Although there are precedents with such package, they all bites. From
SW point of view, the dependence chain is `normal RPMs build requires
portable RPMs` and that's all.
== Contingency Plan ==
* Contingency mechanism: It should be stright forward to revert back
to building per OS
* Contingency deadline: N/A
* Blocks release? No. The change can be introduced even on the fly to
live distributions.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
11 months, 3 weeks
How to fix the "rpma.src: W: strange-permission rpma.spec 600"
warning?
by Xiao Yang
Hi all,
I try to create rpma source package on fedora by fedpkg --release rawhide mockbuild.
The permissions of original rpma.spec is 0644:
$ ll rpma.spec
-rw-r--r--. 1 mockbuild mock 2107 May 25 17:31 rpma.spec
The permissions of rpma.spec in the generated rpma source package is changed to 0600 and then the following warning is triggered by fedpkg --release rawhide lint.
$ fedpkg --release rawhide lint
Failed to get repository name from Git url or pushurl
Failed to get ns from Git url or pushurl
Mockbuild results directory found. Linting mockbuild results.
============ rpmlint session starts ================
rpmlint: 2.4.0
configuration:
/usr/lib/python3.11/site-packages/rpmlint/configdefaults.toml
/etc/xdg/rpmlint/fedora-legacy-licenses.toml
/etc/xdg/rpmlint/fedora-spdx-licenses.toml
/etc/xdg/rpmlint/fedora.toml
/etc/xdg/rpmlint/scoring.toml
/etc/xdg/rpmlint/users-groups.toml
/etc/xdg/rpmlint/warn-on-functions.toml
checks: 31, packages: 4
rpma.src: W: strange-permission rpma.spec 600
3 packages and 1 specfiles checked; 0 errors, 1 warnings, 0 badness; has taken 0.3 s
Could you tell me how to fix the warning?
Best Regards,
Xiao Yang
11 months, 4 weeks
Upcoming retirement of unused compat packages for Rust crates
by Fabio Valentini
Hi all,
I'm planning to do another round of removals of unused Rust crates -
at first. focusing only on compat packages which are no longer useful
since they have no remaining dependent packages in Rawhide.
This includes the gtk-rs v0.16 / gtk4-rs v0.5 compat packages:
- rust-atk0.16
- rust-atk-sys0.16
- rust-cairo-rs0.16
- rust-cairo-sys-rs0.16
- rust-gdk0.16
- rust-gdk-sys0.16
- rust-gdk-pixbuf0.16
- rust-gdk-pixbuf-sys0.16
- rust-gio0.16
- rust-gio-sys0.16
- rust-glib0.16
- rust-glib-sys0.16
- rust-glib-macros0.16
- rust-gobject-sys0.16
- rust-graphene-rs0.16
- rust-graphene-sys0.16
- rust-gtk0.16
- rust-gtk-sys0.16
- rust-gtk3-macros0.16
- rust-pango0.16
- rust-pango-sys0.16
- rust-pangocairo0.16
- rust-pangocairo-sys0.16
- rust-gdk4_0.5
- rust-gdk4-sys0.5
- rust-gsk4_0.5
- rust-gsk4-sys0.5
- rust-gtk4_0.5
- rust-gtk4-sys0.5
- rust-gtk4-macros0.5
- rust-libadwaita0.2
- rust-libadwaita-sys0.2
Side note: The compat packages for the even older gtk-rs v0.15 /
gtk4-rs v0.4 / libadwaita-rs v0.1 cannot be removed yet, since
squeekboard and system76-keyboard-configurator still depend on these
obsolete versions ... :sad face:
Additional (unrelated to gtk-rs) compat packages which are no longer needed:
- rust-libudev0.2
- rust-memmap2_0.3
- rust-cargo_metadata0.12
- rust-tui0.9
- rust-ansi-str0.5
All listed packages are compat packages with newer versions of these
projects already being available in Fedora 37+, and all listed
packages have no dependent packages left. If anybody has objections to
retiring any of these packages despite this, please notify me within
the next 7 days, as I plan to process the retirement of all packages
listed in this email next Monday (June 5).
Fabio
12 months
F39 Change Proposal: Aspell Depreciation (Self-Contained Change)
by Aoife Moloney
https://fedoraproject.org/wiki/Changes/AspellDeprecation
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 ==
Deprecating aspell package because there are better-supported spell
checkers like hunspell/enchant2 which could be used instead. It also
has an upstream with almost 4 years of no action.
== Owner ==
* Name: [[User:ljavorsk| Lukas Javorsky]]
* Email: ljavorsk(a)redhat.com
== Detailed Description ==
Upstream of the aspell package has been inactive for almost 4 years
now. Most of the packages that have been using aspell in the past did
migrate to the supported [https://github.com/hunspell/hunspell
hunspell package] or any other spell checker.
The plan is simple:
1) Deprecate aspell package.
2) Create Bugzilla tracker to request all packages to be migrated to
the hunspell or any other spell checker (let maintainers choose their
preferred one).
3) After all of the packages have been migrated, create a Change to
retire aspell from Fedora
== Feedback ==
Early feedback from the community is located in this
([https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
Devel list announce])
== Benefit to Fedora ==
Fedora shouldn't maintain a dead package. This change will ensure
Fedora has relevant and upstreamed packages in it's repositories.
== Scope ==
* Proposal owners: Package aspell will be deprecated and the migration
request will be filled as a Bugzilla to all dependent packages
* Other developers: Migrate to hunspell package or any other supported
spellchecker present in Fedora repositories.
* Release engineering: No action required
* 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 ==
As this is only deprecation change, nothing will need to be handled
manually. The dependent packages will migrate to hunspell or any other
supported spellchecker present in Fedora repositories.
== How To Test ==
== User Experience ==
== Dependencies ==
List of the packages from Fedora 39
=== Requires ===
repoquery -q --repo=rawhide{,-source} --whatrequires 'aspell*' | grep
-v '^aspell' | grep -v 'src$' | pkgname
eiskaltdcpp-qt
enchant-aspell
enchant2-aspell
kf5-sonnet-core
kf5-sonnet-core
moodle
perl-Code-TidyAll
perl-Text-Aspell
php-pspell
qa-tools
recoll
recoll
xedit
xmlcopyeditor
yagf
=== BuildRequires ===
repoquery -q --repo=rawhide{,-source} --whatrequires 'aspell*' | grep
-v '^aspell' | grep 'src$' | pkgname
eiskaltdcpp
enchant
enchant2
hunspell-az
hunspell-csb
hunspell-de
hunspell-en
hunspell-fa
hunspell-gv
hunspell-ky
ibus-typing-booster
inkscape
kf5-sonnet
logjam
perl-MouseX-ConfigFromFile
perl-MouseX-Types-Path-Class
perl-Text-Aspell
perl-Text-SpellChecker
PHP
recoll
tin
xmlcopyeditor
yagf
== Contingency Plan ==
* Contingency mechanism: No contingency mechanism is required for deprecation.
* Contingency deadline: Beta freeze
* Blocks release? No
''NOTE: If we don't finish this change by the deadline, it is possible
to just complete this change with the next release.''
== Documentation ==
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
12 months
