On Sun, May 5, 2019 at 1:45 PM Zbigniew Jędrzejewski-Szmek
> This makes the assumption, which was also made earlier in the thread,
> that it's somehow impossible to check what bootloader is installed.
> Why? My bootloader is happy to tell me its version:
> $ bootctl
> Current Boot Loader:
> Product: systemd-boot 241-565-g43d51bb
> Features: ✓ Boot counting
> ✓ Menu timeout control
> ✓ One-shot menu timeout control
> ✓ Default entry control
> ✓ One-shot entry control
> File: /EFI/systemd/systemd-bootx64.efi
> Nowadays it's gives the exact git commit it's built from, in the past
> it was just the release version, but either is enough. Therefore
> 'bootctl update' can fairly reliably *update*, i.e. do the installation
> if the thing we have is newer than the version already installed.
That's news to me, and unfortunately it doesn't look as nifty on my system:
Current Boot Loader:
Features: ✗ Boot counting
✗ Menu timeout control
✗ One-shot menu timeout control
✗ Default entry control
✗ One-shot entry control
Available Boot Loaders on ESP:
ESP: /boot/efi (/dev/disk/by-partuuid/$UUID)
Boot Loaders Listed in EFI Variables:
Status: active, boot-order
Title: Linux Firmware Updater
Status: active, boot-order
Where $UUID is the same for all three occurrences.
I am looking for arch container archive files like
" for Fedora 30.
I found the x86_64, aarch64 and s390x's archive files in below directory.
But where is the archive file of armv7hl, i686 and ppc64le?
I assume the multi archs except x86_64, aarch64 and s390x existed in
the age of Fedora 24, 25 in below releases directory.
And why below s390x does not have Fedora-Container-Base-*.tar.xz?
=> No Fedora-Container-Base-*.tar.xz
Jun Aruga / He - His - Him
jaruga(a)redhat.com / IRC: jaruga
== Summary ==
Include Grub's "verify," "cryptodisk" and "luks" modules (and if
necessary, relevant "gcry" modules) in grubx64.efi of the
== Owner ==
* Name: [[User:pjones| Peter Jones]]
* Email: pjones(a)redhat.com
* Name: [[User:javierm| Javier Martinez Canillas]]
* Email: fmartine(a)redhat.com
== Detailed Description ==
Users utilising secure boot functionality on the UEFI platform cannot
insert modules that aren't in grubx64.efi. Paradoxically, this means
that security-conscious users cannot use grub's verify module, or
employ (near) full disk encryption using cryptodisk and luks.
The security benefits of signature verification would reach more users
if Fedora automated it by incorporating the process into
For the long-term, to grant flexibility with grub2 modules on secure
boot instances, it may be advisable to sign the .mod files in the
'grub2-efi-x64-modules' package, modify grub2-mkconfig (or -install)
to copy the necessary modules into the EFI partition when required by
the user's configuration and then allow inserting of signed modules in
secure boot instances.
== Benefit to Fedora ==
This change will allow users to gain trust in the integrity of
early-launch code either through verification of signatures
(particularly useful for initramfs, which is particularly vulnerable
to possible offline modification) or encryption of the boot partition.
== Scope ==
* Proposal owners: Modify grub.macros file to include the
above-mentioned modules in the GRUB_MODULES variable.
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Change only adds modules, so existing users should have no problems.
== How To Test ==
1. Generate a signing key with "gpg --gen-key" and copy it to the EFI partition
2. Add "trust <gpg key>" (but grub may inherit this from shim's MOK)
and "set check_signatures=enforce" to /etc/default/40_custom
3. Run grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
4. Create a file, /tmp/pass, with the key's passphrase, then execute:
for x in $(find /boot -name "*.cfg" -or -name "*.mod" -or -name
"vmlinuz*" -or -name "initramfs*" -or -name "grubenv"); do gpg --batch
--detach-sign --passphrase-fd 0 $x < /tmp/pass; done. Then, shred
5. Reboot. If system starts, change is successful
<b>For cryptography modules:</b>
1. Backup boot partition
2. Run cryptsetup luksFormat <boot partition's block device, for
example, /dev/sda2> --type luks1
3. Open luks container and restore backup
4. Add GRUB_ENABLE_CRYPTODISK=y to /etc/default/grub
5. Confirm that /etc/fstab has the correct UUID for /boot
6. Run grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
7. Reboot. Grub should ask for the password created in step 2. If
system then starts, change is successful
(If filesystem root is also encrypted, user may be asked for a
password twice. This can be mitigated with a keyfile for filesystem
root, or use of the clevis package, and likely, a tpm.)
== User Experience ==
Users may optionally elect to verify the integrity of boot code either
through verification of digital signatures or encryption of the boot
== Dependencies ==
Grub2-efi-x64-modules and grub2-tools-* depend on this package, but
require no change.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Revert the
* Contingency deadline: Beta freeze
* Blocks release? N/A (not a System Wide Change)
* Blocks product? No
== Documentation ==
== Release Notes ==
Fedora now supports Grub's detached verify and cryptodisk
functionality natively, even on secure boot systems.
Fedora Program Manager
I've just spotted these when working on Python 3.8.0a1. This happens on 3.7 as
well since GCC 9:
python3-debug.x86_64: E: library-not-linked-against-libc
python3-debug.x86_64: E: library-not-linked-against-libc
python3-libs.x86_64: E: library-not-linked-against-libc
python3-test.x86_64: E: library-not-linked-against-libc
(Note that there are plenty of other extension modules that do not raise this
This doesn't happen with latest python3 built prior to the gcc update to 9.
$ rpmlint -I library-not-linked-against-libc
That isn't helpful either.
I found a similar Debian thing  that says:
> It is theoretically possible to have a library which doesn't use any symbols
> from libc...
Do I care? Should I fix something? I honestly have no idea.
My name is Gordon Messmer. I've been a long-time user of Red Hat
systems, starting with Red Hat Linux 4.2 in 1997. I've been packaging
software in rpm format for use in business environments for very nearly
as long. I've also been a semi-active member of the Red Hat and Fedora
mailing lists most of those years.
My first contribution will be ansible-bender: a tool that builds
container images using ansible playbooks.
My FAS account is "submachine". I just tried logging into pagure.io, and
while the login succeeded, immediately after, I got a 404 error page with
the error 'No user "submachine" found'. All pagure.io URLs lead to the same
404, so I can't file a pagure issue for this either (which is why I'm
writing to this list after a failed attempt at asking for help on
How can this be fixed?
Dear fellow developers,
I'm no longer able to maintain my packages on Fedora, due to lack of
time and power.
I am maintainer of:
All packages build (as far as I know) except for gnome-dvb-daemon which
failed to build on fc30 mass-rebuild.
The two gnome-shell-extensions should be retired in my opinion, because
they are available via extensions.gnome.org (at the moment), but as I
am also upstream maintainer, the will not be continued (at least not by
I'm also upstream maintainer for aeskulap
(https://github.com/jenslody/aeskulap) but will archive the github-repo
sooner or later.
So if somebody is interested in keeping it, she/he should know this and
probably think about becoming upstream.
If anybody is interested in taking one of the projects, please let me
know and send your fas-name, so I can give it to you.
/,`.-'`' -. ;-;;,_
<|,4- ) )-,_..;\ ( `'-'
A few years ago, I packaged up glibc-arm-linux-gnu, so that Fedora could
have a packaged arm cross-toolchain that was useful (with glibc, it
cannot build anything in userspace). It worked for a while, but lately,
all builds have been failing with this error:
/usr/bin/arm-linux-gnu-ld: skipping incompatible
/usr/lib/gcc/arm-linux-gnueabi/8/libgcc_eh.a when searching for -lgcc_eh
I've looked at it and poked it quite a bit locally, but I can't seem to
get around that. I could really use some help to get this building
again, ideally, updated to 2.28.
All my work is committed to git, no help will be refused.
Thanks in advance,
Today, the Node.js upstream released 12.0.0, the next in its line of
long-term support releases. I plan to make this the default version of
Node.js in Fedora 31+, but not immediately. I'm currently working on
getting a modular version of 12.x built for F29, F30 and Rawhide. I'll
get that out to updates-testing this week. I'll send out an update
once it's pushed to updates-testing.
Once that's available, I encourage all NPM packagers in Fedora to
start testing their build and runtime with the 12.x module. I will be
filing a Change Proposal and plan to switch the system interpreter for
Rawhide over to 12.x around the end of May or beginning of June.
The exact timing may depend on the current status of the
modules-in-the-non-modular-buildroot work in Fedora. If that's
available by this time, I will retire the non-modular Node.js
interpreter package and make the 12.x module the default stream for
F31+. If it's not available, I'll continue to do what I've been doing
in F29 and F30; building both the modular and non-modular packages.
If you discover that you own NPM packages that are critical and do not
work with Node.js 12.x, please inform me immediately. We'll talk with
upstream and see what we can do about it.