In libvirt we recently deleted a driver for the legacy Xen toolstack.
This was shipped in a libvirt-daemon-driver-xen RPM.
I am able to add an "Obsoletes: libvirt-daemon-driver-xen < 4.3.0"
line to the libvirt-daemon-driver-libxl RPM, which gives clean
upgrade path for users.
If they have the libvirt-daemon-driver-xen-debuginfo RPM installed
though that still breaks the upgrade.
How can I get the auto-generated libvirt-daemon-driver-libxl-debuginfo
RPM to have an "Obsoletes: libvirt-daemon-driver-xen-debuginfo < 4.3.0"
statement ? It seems impossible, meaning users with debuginfo have a
broken upgrade path. An unfortunate consequence of switching to seprate
-debuginfo per sub-RPM.
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
I've orphaned python-pep8. pep8 was renamed to pycodestyle in 2016; it
received its last release in 2017. It should be removed from Fedora in a
I unfortunately don't have time to proceed with the full retirement
process myself. If somebody would like to pick it up:
$ dnf repoquery --whatrequires python2-pep8
$ dnf repoquery --whatrequires python3-pep8
See also https://bugzilla.redhat.com/show_bug.cgi?id=1667200's dependent
(Please CC me on replies that need my attention.)
iliana weller <ilianaw(a)buttslol.net>
Do you want to make Fedora 30 better? Please spend 1 minute of your time and try to run:
sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 --enablerepo=updates-testing distro-sync
If you get this prompt:
Total download size: XXX M
Is this ok [y/N]:
you can answer N and nothing happens, no need to test the real upgrade. Upgrades will be fine for you.
But very likely you get some dependency problem now. In that case please report it against appropriate package.
I would like to draw some attention to this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1622259. Description: startx unsets DBUS_SESSION_BUS_ADDRESS, which result in launching another D-Bus session which breaks communicating with user systemd services (and any D-Bus services started before launching X) from X session via D-Bus, since they use two different D-Bus daemons. I would really like this bug to be fixed.
Can somebody please enlighten me, how to update Rawhide after branching
and not using --nogpgcheck?
It seems that Rawhide keys were added in fedora-repos-30-0.4. So this is
the package which is still "rawhide" package and has "f31" keys. But
this package was not probably signed, because this directory is empty:
Installing anything from Rawhide fails, because of missing GPG keys.
So is there a way to get the GPG keys via DNF? Would it be possible to
sign fedora-repos and fedora-release packages by older key to allow
== 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