Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
This entire proposal although has write ideas (I also like to see UKI in Fedora as I have use UKI on Arch and undestand its advantages) is in the wrong. But why start doing UKI without first fixing the need of host specific initrd and commandline. I am sure even non-UEFI users will be better of of not having a host specific initrd. We should first start working on shipping initrd on dedora as an rpm with atleast one use which can be extended by sysext or someother mechanism without the need of UKI first. Once That is possible that UKI can be easily be intgrated and tested. We will be also provide a subset of benefits to the non-UEFI users(for example on other arches). Let first get any gpt or lvm rootfs work with this model then look. Thanks & Regards Marc Pervaz Boocha ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
Hi, > With my FESCo hat on, I immediately have the following comment: > please narrow down the scope to things that we can actually approve > for F38. E.g. the parts related to replacing grub2 by sd-boot > are IMHO not realistic for F38 (*). sd-boot actually replacing grub2 in anaconda installs or cloud images: Yes, that is unrealistic. Building images which use sd-boot with a custom kickstart file (doing 'bootctl install' in %post): That works already. > And if we use grub2, then also the > pre-calculation of TPM PCR values is not realistic, since they are > too volatile with grub2... I think that those are all very interesting > research tangents, but the stuff that gets a stamp of approval as a > Fedora Change needs to be down-to-earth and users-know-what-to-expect > and > you-can-pretty-much-figure-out-how-things-will-look-from-the-change-description. Suggestions how to deal with those best? The reason this stuff is in there is that I want also outline the longer-term goal behind this. I could create a "Phase 2" change page and move over stuff ... thanks & take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
> > == Detailed Description == > > The goal is to move away from initrd images being generated on the > > installed machine. They are generated while building the kernel > > package instead, then shipped as part of a unified kernel image. > > > > A unified kernel image is an all-in-one efi binary containing kernel, > > initrd, cmdline and signature. The secure boot signature covers > > everything, specifically the initrd is included which is not the case > > when the initrd gets loaded as separate file from /boot. > > What platforms are going to be affected? Is it x86-64 only or does it > include aarch64 (as it's also using UEFI)? x86_64 is the primary target. aarch64 possibly too. Secure boot isn't a factor there so it's less important, but having a more robust initrd build and kernel update process is nice to have ... > Are ppc64le and s390x out of the current scope? Yes. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Tue, Dec 20, 2022 at 9:10 PM Kevin Kofler via devel wrote: > > Daniel P. Berrangé wrote: > > That is not correct. There are a number of benefits of UKIs. > > > > The most critical is that the initrd content and cmdline is > > covered by the SecureBoot signature. > > From an end user point of view, having more stuff covered by Restricted Boot > is not a benefit. > I do believe Secure Boot can provide value, but we need to consider it only as "bootstrap security" rather than "boot security". On its face, it's pretty absurd to restrict operating system content to pre-boot signatures. The original goal of secure boot support in Linux was to support the de minimis effort to enable Free platforms to work on PCs where it may not be easy or possible to turn off Secure Boot. There was a very real fear that it would be a reality, which is why we sign our boot code with the Microsoft certificate. But our design deliberately uses the Microsoft certificate to chain into our own. Where we fell apart compared to Windows and macOS is that we decided that we wanted to have all kernel code locked down exclusively by either firmware certificates or hardcoded certificates in shim. In retrospect, this was a bad move because it crippled our ability to enable driver integrity protection for the operating system using similar techniques used by other operating systems. On the flip side, because our own ability to enable and support operating system trust was hamstrung by firmware certificates, we did finally get NVIDIA to open up[1]. Was it the right decision anyway? I don't think so. The way the UAPI group envisions system security clearly shows where this falls apart: we increasingly rely on parts of the system that we have no influence on to guide our system integrity protection. Secure Boot would have been great if it was designed as a user-friendly way to establish and control system content trust. But that's not how it works in practice at all. And the sheer amount of resistance around making it work that way demonstrates how much of a failure it is for that purpose. And it bears repeating: Windows doesn't use Secure Boot for system integrity protection. It has its own in-OS mechanisms instead. As someone whose day job involves working with teams who develop both Windows and Linux drivers (and in the past, even macOS drivers!), I can categorically say that Windows driver engineering processes are way friendlier than Linux ones, precisely because Windows drivers are deliberately not exposed to Secure Boot *at all*. Running development versions of drivers just requires installing a development certificate into the NT kernel certificate store. The equivalent process for Linux is to load a custom secure boot certificate into firmware, which is fraught with peril and potentially not even possible. I cannot tell you how many times I've bricked a system by attempting to load another cert only to find out there's not enough space and the firmware didn't handle that well. We've failed here, badly. And nobody cares. [1]: https://developer.nvidia.com/blog/nvidia-releases-open-source-gpu-kernel-modules/ -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
PS (adding to my previous reply): Daniel P. Berrangé wrote: > The immediate need for UKIs is indeed related to SecureBoot and > TPMs. These are a core technology foundation of the confidential > virtual machine stack. On Azure today, if you request an Ubuntu > confidential VM, Azure will pre-encrypt the root filesystem and So basically this change proposal is about supporting a feature of the Microsoft cloud platform (Azure) in Fedora and will be pretty useless to any user not using Microsoft's platform. > seal the LUKS key against predicted TPM PCR values. It guarantees > that the root disk can only be decrypted by the specific VM > instance that is requested, when it is running in SecureBoot > mode with the expected measurments on AMD SEV-SNP confidential > hardware. Does it really guarantee that, and not just that it can only be decrypted by any VM using the same UKI? How reliably does it ensure that the user can only get root in the decrypted image with the root password (or SSH key or similar) stored inside the image and not through some other means? In the end, if you store data on a "cloud", you are storing it on other people's computers. You are also relying on their confidentiality guarantees. How can you trust the "cloud" provider to actually perform the encryption steps they claim to perform when you check that checkbox, and also to not have a backdoor (such as a fixed master key in an extra LUKS key slot, or a custom, possibly software-emulated, TPM that does not actually keep the key sealed) that allows them to decrypt anything anyway? You are handing off your data to a third party and then trying to rely on Treacherous Computing technologies preventing that third party from doing some things (such as copying the encryption key) on their own computers. I do not think that this is in either party's interest. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Tue, Dec 20, 2022 at 9:04 PM Kevin Kofler via devel wrote: > > Neal Gompa wrote: > > I think Fedora is the only major distro that doesn't do this, > > actually. Mageia and openSUSE do this too. They also use graphical > > GRUB by default instead of plain text GRUB. > > IIRC, the reason that Fedora does not use graphical GRUB by default is that > it at least used to break the NVidia proprietary driver. > That must have not been true for a very long time, because I've never seen this issue in the past 7 years of working on both distros with users with NVIDIA GPUs with the proprietary driver. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
Daniel P. Berrangé wrote: > That is not correct. There are a number of benefits of UKIs. > > The most critical is that the initrd content and cmdline is > covered by the SecureBoot signature. From an end user point of view, having more stuff covered by Restricted Boot is not a benefit. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
Neal Gompa wrote: > I think Fedora is the only major distro that doesn't do this, > actually. Mageia and openSUSE do this too. They also use graphical > GRUB by default instead of plain text GRUB. IIRC, the reason that Fedora does not use graphical GRUB by default is that it at least used to break the NVidia proprietary driver. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)
> On 19 Dec 2022, at 16:50, Jaroslav Mracek wrote: > > I also remember RHEL8 where we ship DNF as YUM. And DNF is very similar to > YUM - both are Python based tool. Anyway in RHEL9 the same tool is shipped as > DNF, because it creates a confusion. And I don't want to experience the same > issue twice. I understand that the name change is always not nice, but > keeping the same name for a different tool is worse. I'm using Oracle Linux 8 at work and some older scripts use "yum" and newer scripts use "dnf" this all just works. What is the confusion that you are trying to avoid? The only issue that I recall from earlier in the thread is that dnf version 5 is not feature complete enough to replace dnf version 4. Is there any database that is corrupted if dnf v4 and dnf v5 commands are mixed on a system? Barry ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Tue, Dec 20, 2022, 4:27 PM Simo Sorce wrote: > On Tue, 2022-12-20 at 14:29 -0500, Neal Gompa wrote: > > Yeah, I seriously doubt this. Linux's model for supporting > > confidential computing is not user-friendly, so I expect low adoption > > and resistance once the flaws become apparent to would-be users. > > > > Neal, you are being unnecessarily negative. And user-friendliness is > directly related to the fact we do not have good support for it. This > proposal would make SecureBoot fundamentally transparent, and if you > don't see it and it works, I see no resistance happening. > > SecureBoot may not be to your liking but is what is installed on 99% of > modern hardware sold, so it is a good idea to first show you can > support it. Then if you have interested you can propose "something > better". > We have supported Secure Boot for over a decade now. In that timeframe, literally nobody did anything to make all the workflows you talk about easier and friendlier. In fact, everyone I talk to seems to think it's basically impossible because of how it works at the firmware level. It's telling that neither Windows nor macOS use Secure Boot like Linux does. And they don't precisely for the reasons I outlined. Finally, unless this proposal harms Fedora I do not see why oppose it. > If, as you fear, it won't work ... then it won't and we'll try > something else. However, having some knowledge of the (security side of > the) matter I do not see why it wouldn't work, once all the pieces fall > in place. > This adds significant complexity to the Fedora kernel package and it effectively increases what we need to test for virtualized Fedora Linux environments. I assert that the proposal has not yet met the bar to overcome those issues. In fact I would love to be able to test this, every time I run updates > I dread the many minutes wasted regenerating initrd when I have a > pretty standard configuration that requires really no special > drivers... the only issue probably being the use of LVM for the root > filesystem, which I hope we'll have a way to deal with (but I can do > without on the laptop). > UKIs need more work to be generally useful, but that would be nice to eliminate if the issues could be fixed. > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Tue, Dec 20, 2022, 4:31 PM Simo Sorce wrote: > On Tue, 2022-12-20 at 20:42 +0100, Björn Persson wrote: > > I note that taking away the kernel command line is indeed a clearly > > stated goal, which will limit Fedora to simple, appliance-like uses. > > I for one, haven't touched once the command line in this laptop that > has 4 years. So I welcome simplification for that *common* case. > Every person who chooses basic graphics mode is triggering this case. The kernel command line is pretty much the first stop for troubleshooting and bypassing driver problems. It's incredibly common even now, which is why we keep hitting bugs and fixing them each release. We are finally starting to automate testing of these modes, so I do not appreciate you saying they are uncommon, because the reality is they are. > > Given nobody is taking away the initrd way all you will have to do (at > most, if you use it) is to disable secure boot and regain the ability > to change the kernel command line and build your own initrd or even > your own kernel if you so like. > This is becoming harder and harder to do. Consumer hardware has not been required to offer that ability in years and I have friends and colleagues who have such hardware today. This is not a realistic expectation to have. And while most still have the capacity to disable it, it is difficult and something we cannot expect users to be able to accomplish. And if you chose your HW carefully you may even be able to register > your own public keys, generate and sign your own built UKIs and re- > enable SecureBoot after that... your choice! > That doesn't mean we should offer any in Fedora itself unless we can be assured someone cares about how regular people are supposed to deal with problems caused by this. > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Tue, 2022-12-20 at 14:56 -0500, Demi Marie Obenour wrote: > How do you plan to handle system recovery? For VMs this is much > less of a concern, but on bare metal there needs to be a way for > a local, authenticated administrator to obtain a root shell on > the system console even if the root filesystem cannot be mounted. > This has saved my system more than once. > > Also, how will Xen be supported in this model? Will the hypervisor > be part of an alternate UKI? CCing Marek Marczykowski-Gorécki of > Qubes OS. It is all answered in the large amount of text you quoted, if you read it carefully. The old kernel+inird does not go away, so you disable secure boot and just use the good old methods, or worst case you use a recovery disk (or USB drive, or whatever you use to install) if you damaged the boot partition. Anything that is not explicitly supported likewise will use the old kernel + custom initrd, you just disable secure boot. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Tue, 2022-12-20 at 20:42 +0100, Björn Persson wrote: > I note that taking away the kernel command line is indeed a clearly > stated goal, which will limit Fedora to simple, appliance-like uses. I for one, haven't touched once the command line in this laptop that has 4 years. So I welcome simplification for that *common* case. Given nobody is taking away the initrd way all you will have to do (at most, if you use it) is to disable secure boot and regain the ability to change the kernel command line and build your own initrd or even your own kernel if you so like. And if you chose your HW carefully you may even be able to register your own public keys, generate and sign your own built UKIs and re- enable SecureBoot after that... your choice! Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Tue, 2022-12-20 at 14:29 -0500, Neal Gompa wrote: > Yeah, I seriously doubt this. Linux's model for supporting > confidential computing is not user-friendly, so I expect low adoption > and resistance once the flaws become apparent to would-be users. > Neal, you are being unnecessarily negative. And user-friendliness is directly related to the fact we do not have good support for it. This proposal would make SecureBoot fundamentally transparent, and if you don't see it and it works, I see no resistance happening. SecureBoot may not be to your liking but is what is installed on 99% of modern hardware sold, so it is a good idea to first show you can support it. Then if you have interested you can propose "something better". Finally, unless this proposal harms Fedora I do not see why oppose it. If, as you fear, it won't work ... then it won't and we'll try something else. However, having some knowledge of the (security side of the) matter I do not see why it wouldn't work, once all the pieces fall in place. In fact I would love to be able to test this, every time I run updates I dread the many minutes wasted regenerating initrd when I have a pretty standard configuration that requires really no special drivers... the only issue probably being the use of LVM for the root filesystem, which I hope we'll have a way to deal with (but I can do without on the laptop). Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
OSTree Native Containers layering examples
Greetings! I wanted to share with our Fedora devel community that the CoreOS layering-examples have matured enough for versioning the repo. At the moment we have 11 examples showing how to create a OCI compliant images that then you can boot into with the features added as part of: https://fedoraproject.org/wiki/Changes/OstreeNativeContainer The release is located at the following link: https://github.com/coreos/layering-examples/releases/tag/v2022.1 All the examples use Fedora CoreOS as their base image, however they should work with any OSTree Native Container that has a recent rpm-ostree version. We don't have an official Kinoite or Silverblue oci container yet but Colin Walters has a pretty cool build here: https://github.com/cgwalters/sync-fedora-ostree-containers We are excited about the possibilities this enables for our users and community and even more excited about seeing people already playing with it. Check out this video by Jorge Castro: https://www.youtube.com/watch?v=X8h304Jp9N8 which shows part of what is possible in action. As we move towards stabilizing these features as part of: https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable We look forward to your contributions and comments. -- Joseph Marrero ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Tue, Dec 20, 2022, at 2:22 PM, Daniel P. Berrangé wrote: > parted/libparted already have support for handling GUIDs since > their 3.5 release. > > I added pyparted support in > > https://github.com/dcantrell/pyparted/pull/95 > > and I've got work in progress for blivet support > > https://github.com/storaged-project/blivet/pull/1080 > > in theory that should merely then require anaconda to set a flag > in blivet to automagicaly enable setting well known GUIDs. > > I've also got some changes to pykickstart to let the GUID be > set in kickstart file part commands. Wow, great news! -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On 12/20/22 10:22, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1 > > 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 == > Add support for unified kernels images to Fedora. > > == Owner == > * Name: [[User:kraxel| Gerd Hoffmann]] > * Email: kra...@redhat.com > > > == Detailed Description == > The goal is to move away from initrd images being generated on the > installed machine. They are generated while building the kernel > package instead, then shipped as part of a unified kernel image. > > A unified kernel image is an all-in-one efi binary containing kernel, > initrd, cmdline and signature. The secure boot signature covers > everything, specifically the initrd is included which is not the case > when the initrd gets loaded as separate file from /boot. > > Main motivation for this move is to make the distro more robust and more > secure. > > Switching the whole distro over to unified kernels quickly is not > realistic though. Too many features are depending on the current > workflow with a host-specific initrd (and host-specific kernel command > line), which is fundamentally incompatible with unified kernels where > everybody will have the same initrd and command line. Thats why there > is 'Phase 1' in title, so we can have more Phases in future releases > 😃 > > A host-specific initrd / command line is needed today for: > > * features needing optional dracut modules (initrd rebuild needed to > enable them). > * configuration / secrets baked into the initrd (booting from iscsi > for example). > * configuration being specified on the kernel command line. > ** root filesystem being the most important one. > [https://systemd.io/DISCOVERABLE_PARTITIONS/ Discoverable partitions] > allow to remove this. > > Phase 1 goals (high priority): > > * Ship a unified kernel image as (optional) kernel sub-rpm. Users can > opt-in to use that kernel by installing the sub-rpm. Initial focus is > on booting virtual machines where we have a relatively small and well > defined set of drivers / features needed. Supporting modern physical > machines with standard setup (i.e. boot from local sata/nvme storage) > too should be easy. > * Update kernel install scripts so unified kernels are installed and > updated properly. > * Add bootloader support for unified kernel images. Add > [https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images > unified kernel bls support] to grub2, or support using systemd-boot, > or both. > > Phase 1 goals (lower priority, might move to Phase 2): > > * Add proper discoverable partitions support to installers (anaconda, > image builder, ...). > ** Temporary workaround possible: set types using sfdisk in %post script. > ** When using btrfs: configure 'root' subvolume as default volume. > * Add proper systemd-boot support to installers. > ** Temporary workaround possible: run 'bootctl install' in %post script. > * Better measurement and remote attestation support. > ** store kernel + initrd hashes somewhere (kernel-hashes.rpm ?) to > allow pre-calculate TPM PCR values. > ** avoid using grub2 (measures every config file line executed which > is next to impossible to pre-calculate). > * Switch cloud images to use unified kernels. > > Phase 2/3 goals (longer-term stuff which is not realistic to complete for > F38). > > * Move away from using the kernel command line for configuration. > * Move away from storing secrets in the initrd. > * Handle dracut optional modules in a different way. > > systemd has some building blocks which can be used, although none of > them are used by fedora today. > [https://www.freedesktop.org/software/systemd/man/systemd-creds.html > systemd credentials] can be used for secrets (also for configuration). > The [https://www.freedesktop.org/software/systemd/man/systemd-stub.html > unified kernel stub] can load credentials from the ESP. > > The unified kernel stub can also load > [https://www.freedesktop.org/software/systemd/man/systemd-sysext.html > extensions] from the ESP, which can possibly be used to replace > optional dracut modules. > > == Feedback == > > > == Benefit to Fedora == > * Better secure boot support (specifically the initrd is covered by > the signature). > * Better confidential computing support (measurements are much more > useful if we know what hashes to expect for the initrd). > * More robust boot process (generating the initrd on the installed > system is fragile, root cause for kernel bugs reported is simply a > broken initrd sometimes). > > == Scope == > * Proposal owners: > ** Update kernel build to create unified kernel sub-package. > *** part one: [https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2179 > PR#2179] > *** part two: (wi
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Tue, Dec 20, 2022, 2:29 PM Neal Gompa wrote: > On Tue, Dec 20, 2022 at 2:02 PM Daniel P. Berrangé > wrote: > > > > On Tue, Dec 20, 2022 at 11:28:48AM -0500, Neal Gompa wrote: > > > On Tue, Dec 20, 2022 at 10:22 AM Ben Cotton > wrote: > > > > > > > > > https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1 > > > > > > > > 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 == > > > > Add support for unified kernels images to Fedora. > > > > > > > > == Owner == > > > > * Name: [[User:kraxel| Gerd Hoffmann]] > > > > * Email: kra...@redhat.com > > > > > > > > > > > > == Detailed Description == > > > > The goal is to move away from initrd images being generated on the > > > > installed machine. They are generated while building the kernel > > > > package instead, then shipped as part of a unified kernel image. > > > > > > > > A unified kernel image is an all-in-one efi binary containing kernel, > > > > initrd, cmdline and signature. The secure boot signature covers > > > > everything, specifically the initrd is included which is not the case > > > > when the initrd gets loaded as separate file from /boot. > > > > > > > > Main motivation for this move is to make the distro more robust and > more secure. > > > > > > > > Switching the whole distro over to unified kernels quickly is not > > > > realistic though. Too many features are depending on the current > > > > workflow with a host-specific initrd (and host-specific kernel > command > > > > line), which is fundamentally incompatible with unified kernels where > > > > everybody will have the same initrd and command line. Thats why there > > > > is 'Phase 1' in title, so we can have more Phases in future releases > > > > 😃 > > > > > > > > A host-specific initrd / command line is needed today for: > > > > > > > > * features needing optional dracut modules (initrd rebuild needed to > > > > enable them). > > > > * configuration / secrets baked into the initrd (booting from iscsi > > > > for example). > > > > * configuration being specified on the kernel command line. > > > > ** root filesystem being the most important one. > > > > [https://systemd.io/DISCOVERABLE_PARTITIONS/ Discoverable > partitions] > > > > allow to remove this. > > > > > > > > Phase 1 goals (high priority): > > > > > > > > * Ship a unified kernel image as (optional) kernel sub-rpm. Users > can > > > > opt-in to use that kernel by installing the sub-rpm. Initial focus > is > > > > on booting virtual machines where we have a relatively small and well > > > > defined set of drivers / features needed. Supporting modern physical > > > > machines with standard setup (i.e. boot from local sata/nvme storage) > > > > too should be easy. > > > > * Update kernel install scripts so unified kernels are installed and > > > > updated properly. > > > > * Add bootloader support for unified kernel images. Add > > > > [ > https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images > > > > unified kernel bls support] to grub2, or support using systemd-boot, > > > > or both. > > > > > > > > Phase 1 goals (lower priority, might move to Phase 2): > > > > > > > > * Add proper discoverable partitions support to installers (anaconda, > > > > image builder, ...). > > > > ** Temporary workaround possible: set types using sfdisk in %post > script. > > > > ** When using btrfs: configure 'root' subvolume as default volume. > > > > * Add proper systemd-boot support to installers. > > > > ** Temporary workaround possible: run 'bootctl install' in %post > script. > > > > * Better measurement and remote attestation support. > > > > ** store kernel + initrd hashes somewhere (kernel-hashes.rpm ?) to > > > > allow pre-calculate TPM PCR values. > > > > ** avoid using grub2 (measures every config file line executed which > > > > is next to impossible to pre-calculate). > > > > * Switch cloud images to use unified kernels. > > > > > > > > Phase 2/3 goals (longer-term stuff which is not realistic to > complete for F38). > > > > > > > > * Move away from using the kernel command line for configuration. > > > > * Move away from storing secrets in the initrd. > > > > * Handle dracut optional modules in a different way. > > > > snip > > > > > > > > I think UKIs are fundamentally flawed and are an idea that came out of > > > a group that doesn't really interact with real users enough to > > > understand how much of a problem they actually are. I realize that > > > this Change is only about VMs, but since it explicitly talks about it > > > being "phase 1", the implication is that future Changes are coming to > > > switch fully over. Consequently, I'm going to provide much more > > > holistic feedback instead of just nitpicking on this case. > > >
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
> Main motivation for this move is to make the distro more robust and more > secure. Improving security would be great, but it must be done in a way that allows the sysadmin to configure and repair the system and authorize the new configuration. > Switching the whole distro over to unified kernels quickly is not > realistic though. Too many features are depending on the current > workflow with a host-specific initrd (and host-specific kernel command > line), which is fundamentally incompatible with unified kernels where > everybody will have the same initrd and command line. Thats why there > is 'Phase 1' in title, so we can have more Phases in future releases > 😃 Whew! So usable kernels won't go away in F38. I only have to worry about being forced to build my own kernels in some unspecified future phase. Doom is still coming but no one knows when. That's *such* a relief. > A host-specific initrd / command line is needed today for: [...] > * configuration being specified on the kernel command line. > ** root filesystem being the most important one. > [https://systemd.io/DISCOVERABLE_PARTITIONS/ Discoverable partitions] > allow to remove this. Why link to a page that only contains a link to another page? Why not link directly to https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ That page makes it clear that omitting root= from the kernel command line is only an *option* which is proposed only "for simpler, appliance-like installations". My workstation and my laptop aren't appliance-like in the slightest. And on appliances you want a stable, reliable operating system, not a fast-moving, unstable one like Fedora. ** Troubleshooting being the second most important one. When the system won't boot, it's necessary to remove "quiet" and "rhgb" from the kernel command line to see how far the boot process gets and what error messages are printed. It may also be necessary to configure a serial console for example. The root filesystem is also relevant for troubleshooting, when I take a storage device out of a broken computer and connect it to another computer to inspect it. Suddenly there are two "discoverable" root partitions, and the kernel parameter is necessary to specify which one is the root filesystem, as stated under "Doesn’t this break multi-boot scenarios?": https://uapi-group.org/specifications/specs/discoverable_partitions_specification/#doesnt-this-break-multi-boot-scenarios > Phase 2/3 goals (longer-term stuff which is not realistic to complete for > F38). > > * Move away from using the kernel command line for configuration. I note that taking away the kernel command line is indeed a clearly stated goal, which will limit Fedora to simple, appliance-like uses. If any of what I wrote above misrepresents the change owner's intentions, then the change proposal is badly written and needs reworking to communicate the true intentions. Björn Persson pgpivDr3FEwyq.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Tue, Dec 20, 2022 at 2:02 PM Daniel P. Berrangé wrote: > > On Tue, Dec 20, 2022 at 11:28:48AM -0500, Neal Gompa wrote: > > On Tue, Dec 20, 2022 at 10:22 AM Ben Cotton wrote: > > > > > > https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1 > > > > > > 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 == > > > Add support for unified kernels images to Fedora. > > > > > > == Owner == > > > * Name: [[User:kraxel| Gerd Hoffmann]] > > > * Email: kra...@redhat.com > > > > > > > > > == Detailed Description == > > > The goal is to move away from initrd images being generated on the > > > installed machine. They are generated while building the kernel > > > package instead, then shipped as part of a unified kernel image. > > > > > > A unified kernel image is an all-in-one efi binary containing kernel, > > > initrd, cmdline and signature. The secure boot signature covers > > > everything, specifically the initrd is included which is not the case > > > when the initrd gets loaded as separate file from /boot. > > > > > > Main motivation for this move is to make the distro more robust and more > > > secure. > > > > > > Switching the whole distro over to unified kernels quickly is not > > > realistic though. Too many features are depending on the current > > > workflow with a host-specific initrd (and host-specific kernel command > > > line), which is fundamentally incompatible with unified kernels where > > > everybody will have the same initrd and command line. Thats why there > > > is 'Phase 1' in title, so we can have more Phases in future releases > > > 😃 > > > > > > A host-specific initrd / command line is needed today for: > > > > > > * features needing optional dracut modules (initrd rebuild needed to > > > enable them). > > > * configuration / secrets baked into the initrd (booting from iscsi > > > for example). > > > * configuration being specified on the kernel command line. > > > ** root filesystem being the most important one. > > > [https://systemd.io/DISCOVERABLE_PARTITIONS/ Discoverable partitions] > > > allow to remove this. > > > > > > Phase 1 goals (high priority): > > > > > > * Ship a unified kernel image as (optional) kernel sub-rpm. Users can > > > opt-in to use that kernel by installing the sub-rpm. Initial focus is > > > on booting virtual machines where we have a relatively small and well > > > defined set of drivers / features needed. Supporting modern physical > > > machines with standard setup (i.e. boot from local sata/nvme storage) > > > too should be easy. > > > * Update kernel install scripts so unified kernels are installed and > > > updated properly. > > > * Add bootloader support for unified kernel images. Add > > > [https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images > > > unified kernel bls support] to grub2, or support using systemd-boot, > > > or both. > > > > > > Phase 1 goals (lower priority, might move to Phase 2): > > > > > > * Add proper discoverable partitions support to installers (anaconda, > > > image builder, ...). > > > ** Temporary workaround possible: set types using sfdisk in %post script. > > > ** When using btrfs: configure 'root' subvolume as default volume. > > > * Add proper systemd-boot support to installers. > > > ** Temporary workaround possible: run 'bootctl install' in %post script. > > > * Better measurement and remote attestation support. > > > ** store kernel + initrd hashes somewhere (kernel-hashes.rpm ?) to > > > allow pre-calculate TPM PCR values. > > > ** avoid using grub2 (measures every config file line executed which > > > is next to impossible to pre-calculate). > > > * Switch cloud images to use unified kernels. > > > > > > Phase 2/3 goals (longer-term stuff which is not realistic to complete for > > > F38). > > > > > > * Move away from using the kernel command line for configuration. > > > * Move away from storing secrets in the initrd. > > > * Handle dracut optional modules in a different way. > > snip > > > > > I think UKIs are fundamentally flawed and are an idea that came out of > > a group that doesn't really interact with real users enough to > > understand how much of a problem they actually are. I realize that > > this Change is only about VMs, but since it explicitly talks about it > > being "phase 1", the implication is that future Changes are coming to > > switch fully over. Consequently, I'm going to provide much more > > holistic feedback instead of just nitpicking on this case. > > The future "phase 2/3" goal are mentioned above, and don't > mention fully switching to UKIs. > > I don't anticipate such a switch being realistic any time > in the forseeable future. There are too many unknowns, in > addition to some points you mentioned, to
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Tue, Dec 20, 2022 at 01:56:57PM -0500, Chris Murphy wrote: > > > On Tue, Dec 20, 2022, at 10:22 AM, Ben Cotton wrote: > > > == Detailed Description == > > The goal is to move away from initrd images being generated on the > > installed machine. They are generated while building the kernel > > package instead, then shipped as part of a unified kernel image. > > > > A unified kernel image is an all-in-one efi binary containing kernel, > > initrd, cmdline and signature. The secure boot signature covers > > everything, specifically the initrd is included which is not the case > > when the initrd gets loaded as separate file from /boot. > > > > Main motivation for this move is to make the distro more robust and more > > secure. > > > > Switching the whole distro over to unified kernels quickly is not > > realistic though. Too many features are depending on the current > > workflow with a host-specific initrd (and host-specific kernel command > > line), which is fundamentally incompatible with unified kernels where > > everybody will have the same initrd and command line. Thats why there > > is 'Phase 1' in title, so we can have more Phases in future releases > > 😃 > > > > A host-specific initrd / command line is needed today for: > > > > * features needing optional dracut modules (initrd rebuild needed to > > enable them). > > * configuration / secrets baked into the initrd (booting from iscsi > > for example). > > * configuration being specified on the kernel command line. > > ** root filesystem being the most important one. > > [https://systemd.io/DISCOVERABLE_PARTITIONS/ Discoverable partitions] > > allow to remove this. > > Discoverable partitions is the first barrier in the proposal. I agree with > everything up to this point. I like discoverable partitions specification, > the gotcha is there is the significant amount of inertia still against > trusting GPT partition type GUIDs. They tend to be entirely ignored in Linux. > Yes systemd honors them, but the installer is pretty weak in its > understanding of them, and by extention parted/libparted lacks support for > (a) the entire discoverable partitions spec's listing of type GUIDs (b) > arbitrary GUIDs. > > So I think the first big barrier to entry is answering the questions: > > * Enhance parted/libparted to support arbitrary GUIDs and > enhance blivet to understand the full listing of GUIDs? Or parted/libparted already have support for handling GUIDs since their 3.5 release. I added pyparted support in https://github.com/dcantrell/pyparted/pull/95 and I've got work in progress for blivet support https://github.com/storaged-project/blivet/pull/1080 in theory that should merely then require anaconda to set a flag in blivet to automagicaly enable setting well known GUIDs. I've also got some changes to pykickstart to let the GUID be set in kickstart file part commands. > > Phase 1 goals (high priority): > > > > * Ship a unified kernel image as (optional) kernel sub-rpm. Users can > > opt-in to use that kernel by installing the sub-rpm. Initial focus is > > on booting virtual machines where we have a relatively small and well > > defined set of drivers / features needed. Supporting modern physical > > machines with standard setup (i.e. boot from local sata/nvme storage) > > too should be easy. > > I like the focus on VM's so long as it drives us forward incrementally > in a way we can then converge baremetal back toward rather than > fragmenting. I'm skeptical this is going to be easy to do on baremetal... > more in a bit. Yes, bare metal is certainly harder due to the much wider variance in boot hardware and also users tend todo much more complex thing. The focus on VMs was intentional to make the problem more tractable to solve. Even for VMs this proposal doesn't solve every use case. It is anticipated things will evolve incrementally over time to cover more use cases for both VMs & bare metal. The existing way of booting kernels+locally created initrds isn't going anywhere, so we're not loosing any features. > > * Add bootloader support for unified kernel images. Add > > [https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images > > unified kernel bls support] to grub2, or support using systemd-boot, > > or both. > > Great. Just be aware the bootloader team is somewhere between > disinterested in Boot Loader Specification, and hostile to it. > They support the BLS snippet file format. Beyond that, there > is defiance of the specification as an actual bonefide spec > that Fedora does or even should support. And because of that > you can expect breakage. > > For example: > https://bugzilla.redhat.com/show_bug.cgi?id=2120845 > > For that matter, grubby likewise steps on *all* BLS snippets > found in /boot/loader/entries when using the --update=ALL > flag, not just the BLS snippets As part of virtualization work with confidential VMs we are in active discussions/collaboration with people
Announcing libquotient soversion bump
Hello all. libquotient 0.7.0 will include a soversion bump from .0.6 to .0.7. This release includes both ABI and API changes: https://github.com/quotient-im/libQuotient/releases/tag/0.7.0 Affected packages: - neochat - quaternion - spectral (retired, will be replaced by neochat) I will rebuild the dependent packages in a separate side tag for Fedora 37 and Rawhide. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Tue, Dec 20, 2022, at 1:56 PM, Chris Murphy wrote: > For example: > https://bugzilla.redhat.com/show_bug.cgi?id=2120845 > > For that matter, grubby likewise steps on *all* BLS snippets found in > /boot/loader/entries when using the --update=ALL flag, not just the BLS > snippets Incomplete thought: --update=ALL modifies all snippets in /boot/loader/entries, not just the BLS snippets the currently running root owns. This brings up the concept of each installed distro, whether literally a different distro or merely an additional instance of the same distro, having ownership of its BLS snippets and not owning other BLS snippets. Fedora A should not be modifying Fedora B's BLS snipets, but it does. And now breaks them since the change earlier this year mentioned in the bug. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Tue, Dec 20, 2022 at 11:28:48AM -0500, Neal Gompa wrote: > On Tue, Dec 20, 2022 at 10:22 AM Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1 > > > > 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 == > > Add support for unified kernels images to Fedora. > > > > == Owner == > > * Name: [[User:kraxel| Gerd Hoffmann]] > > * Email: kra...@redhat.com > > > > > > == Detailed Description == > > The goal is to move away from initrd images being generated on the > > installed machine. They are generated while building the kernel > > package instead, then shipped as part of a unified kernel image. > > > > A unified kernel image is an all-in-one efi binary containing kernel, > > initrd, cmdline and signature. The secure boot signature covers > > everything, specifically the initrd is included which is not the case > > when the initrd gets loaded as separate file from /boot. > > > > Main motivation for this move is to make the distro more robust and more > > secure. > > > > Switching the whole distro over to unified kernels quickly is not > > realistic though. Too many features are depending on the current > > workflow with a host-specific initrd (and host-specific kernel command > > line), which is fundamentally incompatible with unified kernels where > > everybody will have the same initrd and command line. Thats why there > > is 'Phase 1' in title, so we can have more Phases in future releases > > 😃 > > > > A host-specific initrd / command line is needed today for: > > > > * features needing optional dracut modules (initrd rebuild needed to > > enable them). > > * configuration / secrets baked into the initrd (booting from iscsi > > for example). > > * configuration being specified on the kernel command line. > > ** root filesystem being the most important one. > > [https://systemd.io/DISCOVERABLE_PARTITIONS/ Discoverable partitions] > > allow to remove this. > > > > Phase 1 goals (high priority): > > > > * Ship a unified kernel image as (optional) kernel sub-rpm. Users can > > opt-in to use that kernel by installing the sub-rpm. Initial focus is > > on booting virtual machines where we have a relatively small and well > > defined set of drivers / features needed. Supporting modern physical > > machines with standard setup (i.e. boot from local sata/nvme storage) > > too should be easy. > > * Update kernel install scripts so unified kernels are installed and > > updated properly. > > * Add bootloader support for unified kernel images. Add > > [https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images > > unified kernel bls support] to grub2, or support using systemd-boot, > > or both. > > > > Phase 1 goals (lower priority, might move to Phase 2): > > > > * Add proper discoverable partitions support to installers (anaconda, > > image builder, ...). > > ** Temporary workaround possible: set types using sfdisk in %post script. > > ** When using btrfs: configure 'root' subvolume as default volume. > > * Add proper systemd-boot support to installers. > > ** Temporary workaround possible: run 'bootctl install' in %post script. > > * Better measurement and remote attestation support. > > ** store kernel + initrd hashes somewhere (kernel-hashes.rpm ?) to > > allow pre-calculate TPM PCR values. > > ** avoid using grub2 (measures every config file line executed which > > is next to impossible to pre-calculate). > > * Switch cloud images to use unified kernels. > > > > Phase 2/3 goals (longer-term stuff which is not realistic to complete for > > F38). > > > > * Move away from using the kernel command line for configuration. > > * Move away from storing secrets in the initrd. > > * Handle dracut optional modules in a different way. snip > > I think UKIs are fundamentally flawed and are an idea that came out of > a group that doesn't really interact with real users enough to > understand how much of a problem they actually are. I realize that > this Change is only about VMs, but since it explicitly talks about it > being "phase 1", the implication is that future Changes are coming to > switch fully over. Consequently, I'm going to provide much more > holistic feedback instead of just nitpicking on this case. The future "phase 2/3" goal are mentioned above, and don't mention fully switching to UKIs. I don't anticipate such a switch being realistic any time in the forseeable future. There are too many unknowns, in addition to some points you mentioned, to even consider that right now. The in place upgrade story gogin from locally generated initrd, with arbitrary user chosen content to a UKI doesn't even bare thinking about. I don't think that's even possible to achieve in a seemless way given the infinite number of v
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Tue, Dec 20, 2022, at 1:56 PM, Chris Murphy wrote: > So I think the first big barrier to entry is answering the questions: > > * Enhance parted/libparted to support arbitrary GUIDs and enhance > blivet to understand the full listing of GUIDs? Or > > * Enhance parted/libparted to support full listing of GUIDs? Or > > * switch anaconda/blivet to using fdisk/libfdisk? It already supports > pretty much all GPT partition type GUIDs and receives regular updates > with additions; I'm not sure if it supports arbitrary GUIDs, the CLI > tool seems not to support it but maybe fdisk does. Typo: maybe libfdisk does (support arbitrary partition type GUIDs) -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Tue, Dec 20, 2022, at 10:22 AM, Ben Cotton wrote: > == Detailed Description == > The goal is to move away from initrd images being generated on the > installed machine. They are generated while building the kernel > package instead, then shipped as part of a unified kernel image. > > A unified kernel image is an all-in-one efi binary containing kernel, > initrd, cmdline and signature. The secure boot signature covers > everything, specifically the initrd is included which is not the case > when the initrd gets loaded as separate file from /boot. > > Main motivation for this move is to make the distro more robust and more > secure. > > Switching the whole distro over to unified kernels quickly is not > realistic though. Too many features are depending on the current > workflow with a host-specific initrd (and host-specific kernel command > line), which is fundamentally incompatible with unified kernels where > everybody will have the same initrd and command line. Thats why there > is 'Phase 1' in title, so we can have more Phases in future releases > 😃 > > A host-specific initrd / command line is needed today for: > > * features needing optional dracut modules (initrd rebuild needed to > enable them). > * configuration / secrets baked into the initrd (booting from iscsi > for example). > * configuration being specified on the kernel command line. > ** root filesystem being the most important one. > [https://systemd.io/DISCOVERABLE_PARTITIONS/ Discoverable partitions] > allow to remove this. Discoverable partitions is the first barrier in the proposal. I agree with everything up to this point. I like discoverable partitions specification, the gotcha is there is the significant amount of inertia still against trusting GPT partition type GUIDs. They tend to be entirely ignored in Linux. Yes systemd honors them, but the installer is pretty weak in its understanding of them, and by extention parted/libparted lacks support for (a) the entire discoverable partitions spec's listing of type GUIDs (b) arbitrary GUIDs. So I think the first big barrier to entry is answering the questions: * Enhance parted/libparted to support arbitrary GUIDs and enhance blivet to understand the full listing of GUIDs? Or * Enhance parted/libparted to support full listing of GUIDs? Or * switch anaconda/blivet to using fdisk/libfdisk? It already supports pretty much all GPT partition type GUIDs and receives regular updates with additions; I'm not sure if it supports arbitrary GUIDs, the CLI tool seems not to support it but maybe fdisk does. > Phase 1 goals (high priority): > > * Ship a unified kernel image as (optional) kernel sub-rpm. Users can > opt-in to use that kernel by installing the sub-rpm. Initial focus is > on booting virtual machines where we have a relatively small and well > defined set of drivers / features needed. Supporting modern physical > machines with standard setup (i.e. boot from local sata/nvme storage) > too should be easy. I like the focus on VM's so long as it drives us forward incrementally in a way we can then converge baremetal back toward rather than fragmenting. I'm skeptical this is going to be easy to do on baremetal... more in a bit. > * Add bootloader support for unified kernel images. Add > [https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images > unified kernel bls support] to grub2, or support using systemd-boot, > or both. Great. Just be aware the bootloader team is somewhere between disinterested in Boot Loader Specification, and hostile to it. They support the BLS snippet file format. Beyond that, there is defiance of the specification as an actual bonefide spec that Fedora does or even should support. And because of that you can expect breakage. For example: https://bugzilla.redhat.com/show_bug.cgi?id=2120845 For that matter, grubby likewise steps on *all* BLS snippets found in /boot/loader/entries when using the --update=ALL flag, not just the BLS snippets > ** When using btrfs: configure 'root' subvolume as default volume. The installer understands `btrfs subvolume set-default` so it could set the "root" subvolume. The difficulty I've always had with this, it's that it's not discoverable. There's no way someone not already familiar with the concept of changing the default subvolume would ever figure this out on their own, and I'm a big fan of the boot process being verbose and explicit. Anytime there's silent leaps of faith, it's harder to trouble shoot, and harder still for mortal users to understand how their system functions. But maybe this can be mitigated by e.g. the kernel's btrfs driver announcing the subvolume/subvolume ID it's mounting when it's not explicit (i.e. when it's honoring a subvolume other than ID 5, set as the default subvolume) Previously I've mentioned expanding the discoverable partitions conceptually, a sort of "discoverable subvolumes spec" so that Btrfs and OSTree and LVM could benefit
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Tue, Dec 20, 2022 at 1:18 PM Hans de Goede wrote: > > Hi, > > On 12/20/22 17:28, Neal Gompa wrote: > > On Tue, Dec 20, 2022 at 10:22 AM Ben Cotton wrote: > >> > >> https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1 > >> > >> 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 == > >> Add support for unified kernels images to Fedora. > >> > >> == Owner == > >> * Name: [[User:kraxel| Gerd Hoffmann]] > >> * Email: kra...@redhat.com > >> > >> > >> == Detailed Description == > >> The goal is to move away from initrd images being generated on the > >> installed machine. They are generated while building the kernel > >> package instead, then shipped as part of a unified kernel image. > >> > >> A unified kernel image is an all-in-one efi binary containing kernel, > >> initrd, cmdline and signature. The secure boot signature covers > >> everything, specifically the initrd is included which is not the case > >> when the initrd gets loaded as separate file from /boot. > >> > >> Main motivation for this move is to make the distro more robust and more > >> secure. > >> > >> Switching the whole distro over to unified kernels quickly is not > >> realistic though. Too many features are depending on the current > >> workflow with a host-specific initrd (and host-specific kernel command > >> line), which is fundamentally incompatible with unified kernels where > >> everybody will have the same initrd and command line. Thats why there > >> is 'Phase 1' in title, so we can have more Phases in future releases > >> 😃 > >> > >> A host-specific initrd / command line is needed today for: > >> > >> * features needing optional dracut modules (initrd rebuild needed to > >> enable them). > >> * configuration / secrets baked into the initrd (booting from iscsi > >> for example). > >> * configuration being specified on the kernel command line. > >> ** root filesystem being the most important one. > >> [https://systemd.io/DISCOVERABLE_PARTITIONS/ Discoverable partitions] > >> allow to remove this. > >> > >> Phase 1 goals (high priority): > >> > >> * Ship a unified kernel image as (optional) kernel sub-rpm. Users can > >> opt-in to use that kernel by installing the sub-rpm. Initial focus is > >> on booting virtual machines where we have a relatively small and well > >> defined set of drivers / features needed. Supporting modern physical > >> machines with standard setup (i.e. boot from local sata/nvme storage) > >> too should be easy. > >> * Update kernel install scripts so unified kernels are installed and > >> updated properly. > >> * Add bootloader support for unified kernel images. Add > >> [https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images > >> unified kernel bls support] to grub2, or support using systemd-boot, > >> or both. > >> > >> Phase 1 goals (lower priority, might move to Phase 2): > >> > >> * Add proper discoverable partitions support to installers (anaconda, > >> image builder, ...). > >> ** Temporary workaround possible: set types using sfdisk in %post script. > >> ** When using btrfs: configure 'root' subvolume as default volume. > >> * Add proper systemd-boot support to installers. > >> ** Temporary workaround possible: run 'bootctl install' in %post script. > >> * Better measurement and remote attestation support. > >> ** store kernel + initrd hashes somewhere (kernel-hashes.rpm ?) to > >> allow pre-calculate TPM PCR values. > >> ** avoid using grub2 (measures every config file line executed which > >> is next to impossible to pre-calculate). > >> * Switch cloud images to use unified kernels. > >> > >> Phase 2/3 goals (longer-term stuff which is not realistic to complete for > >> F38). > >> > >> * Move away from using the kernel command line for configuration. > >> * Move away from storing secrets in the initrd. > >> * Handle dracut optional modules in a different way. > >> > >> systemd has some building blocks which can be used, although none of > >> them are used by fedora today. > >> [https://www.freedesktop.org/software/systemd/man/systemd-creds.html > >> systemd credentials] can be used for secrets (also for configuration). > >> The [https://www.freedesktop.org/software/systemd/man/systemd-stub.html > >> unified kernel stub] can load credentials from the ESP. > >> > >> The unified kernel stub can also load > >> [https://www.freedesktop.org/software/systemd/man/systemd-sysext.html > >> extensions] from the ESP, which can possibly be used to replace > >> optional dracut modules. > >> > >> == Feedback == > >> > >> > >> == Benefit to Fedora == > >> * Better secure boot support (specifically the initrd is covered by > >> the signature). > >> * Better confidential computing support (measurements are much more > >> useful if we kn
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
Hi, On 12/20/22 17:28, Neal Gompa wrote: > On Tue, Dec 20, 2022 at 10:22 AM Ben Cotton wrote: >> >> https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1 >> >> 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 == >> Add support for unified kernels images to Fedora. >> >> == Owner == >> * Name: [[User:kraxel| Gerd Hoffmann]] >> * Email: kra...@redhat.com >> >> >> == Detailed Description == >> The goal is to move away from initrd images being generated on the >> installed machine. They are generated while building the kernel >> package instead, then shipped as part of a unified kernel image. >> >> A unified kernel image is an all-in-one efi binary containing kernel, >> initrd, cmdline and signature. The secure boot signature covers >> everything, specifically the initrd is included which is not the case >> when the initrd gets loaded as separate file from /boot. >> >> Main motivation for this move is to make the distro more robust and more >> secure. >> >> Switching the whole distro over to unified kernels quickly is not >> realistic though. Too many features are depending on the current >> workflow with a host-specific initrd (and host-specific kernel command >> line), which is fundamentally incompatible with unified kernels where >> everybody will have the same initrd and command line. Thats why there >> is 'Phase 1' in title, so we can have more Phases in future releases >> 😃 >> >> A host-specific initrd / command line is needed today for: >> >> * features needing optional dracut modules (initrd rebuild needed to >> enable them). >> * configuration / secrets baked into the initrd (booting from iscsi >> for example). >> * configuration being specified on the kernel command line. >> ** root filesystem being the most important one. >> [https://systemd.io/DISCOVERABLE_PARTITIONS/ Discoverable partitions] >> allow to remove this. >> >> Phase 1 goals (high priority): >> >> * Ship a unified kernel image as (optional) kernel sub-rpm. Users can >> opt-in to use that kernel by installing the sub-rpm. Initial focus is >> on booting virtual machines where we have a relatively small and well >> defined set of drivers / features needed. Supporting modern physical >> machines with standard setup (i.e. boot from local sata/nvme storage) >> too should be easy. >> * Update kernel install scripts so unified kernels are installed and >> updated properly. >> * Add bootloader support for unified kernel images. Add >> [https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images >> unified kernel bls support] to grub2, or support using systemd-boot, >> or both. >> >> Phase 1 goals (lower priority, might move to Phase 2): >> >> * Add proper discoverable partitions support to installers (anaconda, >> image builder, ...). >> ** Temporary workaround possible: set types using sfdisk in %post script. >> ** When using btrfs: configure 'root' subvolume as default volume. >> * Add proper systemd-boot support to installers. >> ** Temporary workaround possible: run 'bootctl install' in %post script. >> * Better measurement and remote attestation support. >> ** store kernel + initrd hashes somewhere (kernel-hashes.rpm ?) to >> allow pre-calculate TPM PCR values. >> ** avoid using grub2 (measures every config file line executed which >> is next to impossible to pre-calculate). >> * Switch cloud images to use unified kernels. >> >> Phase 2/3 goals (longer-term stuff which is not realistic to complete for >> F38). >> >> * Move away from using the kernel command line for configuration. >> * Move away from storing secrets in the initrd. >> * Handle dracut optional modules in a different way. >> >> systemd has some building blocks which can be used, although none of >> them are used by fedora today. >> [https://www.freedesktop.org/software/systemd/man/systemd-creds.html >> systemd credentials] can be used for secrets (also for configuration). >> The [https://www.freedesktop.org/software/systemd/man/systemd-stub.html >> unified kernel stub] can load credentials from the ESP. >> >> The unified kernel stub can also load >> [https://www.freedesktop.org/software/systemd/man/systemd-sysext.html >> extensions] from the ESP, which can possibly be used to replace >> optional dracut modules. >> >> == Feedback == >> >> >> == Benefit to Fedora == >> * Better secure boot support (specifically the initrd is covered by >> the signature). >> * Better confidential computing support (measurements are much more >> useful if we know what hashes to expect for the initrd). >> * More robust boot process (generating the initrd on the installed >> system is fragile, root cause for kernel bugs reported is simply a >> broken initrd sometimes). >> >> == Scope == >> * Proposal owners: >> ** Update kernel buil
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Tue, Dec 20, 2022 at 04:38:37PM +0100, Dan Horák wrote: > On Tue, 20 Dec 2022 10:22:03 -0500 > Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1 > > > > 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 == > > Add support for unified kernels images to Fedora. > > > > == Owner == > > * Name: [[User:kraxel| Gerd Hoffmann]] > > * Email: kra...@redhat.com > > > > > > == Detailed Description == > > The goal is to move away from initrd images being generated on the > > installed machine. They are generated while building the kernel > > package instead, then shipped as part of a unified kernel image. > > > > A unified kernel image is an all-in-one efi binary containing kernel, > > initrd, cmdline and signature. The secure boot signature covers > > everything, specifically the initrd is included which is not the case > > when the initrd gets loaded as separate file from /boot. > > What platforms are going to be affected? Is it x86-64 only or does it > include aarch64 (as it's also using UEFI)? Are ppc64le and s390x out of > the current scope? This change proposal would only be x86_64, since that's the platform where we need to solve the unsigned initrd problem with SecureBoot with EDK2/QEMU (and more generally with bare metal, but this change is limited scope to VMs to make it tractable to pre-built initrds with a fixed set of kmods). While aarch64 uses UEFI, there's no viable SecureBoot support for it in EDK2/QEMU yet. If and when that appears, then it could be extended to aarch64 at that time. There's no plans for ppc64le / s390x. NB, I'm talking from the POV of what we require to address as virtualization platform maintainers. There might be other use cases for UKIs from other teams TBD. With regards, Daniel -- |: 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 :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
LibRaw soname bump
LibRaw 0.21.0 is coming to rawhide. This will impact several packages; I'll handle the rebuilds in a side tag. -- Gwyn Ciesla she/her/hers in your fear, seek only peace in your fear, seek only love -d. bowie Sent with Proton Mail secure email. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Tue, Dec 20, 2022 at 04:22:39PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Dec 20, 2022 at 10:22:03AM -0500, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1 > > It's great to see this happening! > > > Phase 1 goals (high priority): > > > > * Ship a unified kernel image as (optional) kernel sub-rpm. Users can > > opt-in to use that kernel by installing the sub-rpm. Initial focus is > > on booting virtual machines where we have a relatively small and well > > defined set of drivers / features needed. Supporting modern physical > > machines with standard setup (i.e. boot from local sata/nvme storage) > > too should be easy. > > * Update kernel install scripts so unified kernels are installed and > > updated properly. > > * Add bootloader support for unified kernel images. Add > > [https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images > > unified kernel bls support] to grub2, or support using systemd-boot, > > or both. > > > > Phase 1 goals (lower priority, might move to Phase 2): > > > > * Add proper discoverable partitions support to installers (anaconda, > > image builder, ...). > > ** Temporary workaround possible: set types using sfdisk in %post script. > > ** When using btrfs: configure 'root' subvolume as default volume. > > * Add proper systemd-boot support to installers. > > ** Temporary workaround possible: run 'bootctl install' in %post script. > > * Better measurement and remote attestation support. > > ** store kernel + initrd hashes somewhere (kernel-hashes.rpm ?) to > > allow pre-calculate TPM PCR values. > > ** avoid using grub2 (measures every config file line executed which > > is next to impossible to pre-calculate). > > * Switch cloud images to use unified kernels. > > With my FESCo hat on, I immediately have the following comment: > please narrow down the scope to things that we can actually approve > for F38. E.g. the parts related to replacing grub2 by sd-boot > are IMHO not realistic for F38 (*). And if we use grub2, then also the > pre-calculation of TPM PCR values is not realistic, since they are > too volatile with grub2... I think that those are all very interesting > research tangents, but the stuff that gets a stamp of approval as a > Fedora Change needs to be down-to-earth and users-know-what-to-expect > and > you-can-pretty-much-figure-out-how-things-will-look-from-the-change-description. > > (*) Or if that is actually the plan, please specify *where* sd-boot > would be supported. The 'description' text there somewhat contradicts the 'Scope' section, which only mentions grub2, not sd-boot: Proposal owners: Update kernel build to create unified kernel sub-package. part one: PR#2179 part two: (wip) https://gitlab.com/kraxel/kernel-ark/-/commits/unified/ Other developers: grub2: add unified kernel support wip code at https://github.com/osteffenrh/grub2/ installer(s): add support for discoverable partitions. Bug#1075288 While use of sd-boot is desirable in many ways, it is not a pre-requisite for the use of UKIs. For that matter neither is the grub2 support. IMHO keeping sd-boot separate from this change though is better to avoid us getting diverted into a huge debate about bootloader choices for Fedora, as that's a huge topic in its own right. As noted there are some WIP patches for grub to allow it to load UKIs. This would let us address the major hole in grub where initrds are not signed for SecureBoot. As yuo mention, grub PCRs calculations are still complex / fragile. Without grub2 support for UKIs, and without sd-boot signed by Fedora, UKIs are still useful. shim can be configured to directly boot the UKI, at which point the PCR calculations are pretty easy [1]. For virtual machines with pre-built disk images, a boot loader can be considered redundant for common use, as with public cloud users rarely even see the bootloader phase of boot, let alone bother trying to interact with it. This is actually desirable for confidential VMs, as you don't want to be interacting with the guest over a virtual keyboard/console, as that's not a confidential channel. IOW, I think scope of this change should be UKIs as the mandatory deliverable, and grub2 support for UKIs as a nice-to-have, and anything about sd-boot strictly as a separate Change (whether f38 or F$later TBD) With regards, Daniel [1] I've got an experimental tool for doing PCR pre-calculations https://gitlab.com/berrange/tpm-prevision/ -- |: 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 :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fe
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Tue, Dec 20, 2022 at 10:22 AM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1 > > 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 == > Add support for unified kernels images to Fedora. > > == Owner == > * Name: [[User:kraxel| Gerd Hoffmann]] > * Email: kra...@redhat.com > > > == Detailed Description == > The goal is to move away from initrd images being generated on the > installed machine. They are generated while building the kernel > package instead, then shipped as part of a unified kernel image. > > A unified kernel image is an all-in-one efi binary containing kernel, > initrd, cmdline and signature. The secure boot signature covers > everything, specifically the initrd is included which is not the case > when the initrd gets loaded as separate file from /boot. > > Main motivation for this move is to make the distro more robust and more > secure. > > Switching the whole distro over to unified kernels quickly is not > realistic though. Too many features are depending on the current > workflow with a host-specific initrd (and host-specific kernel command > line), which is fundamentally incompatible with unified kernels where > everybody will have the same initrd and command line. Thats why there > is 'Phase 1' in title, so we can have more Phases in future releases > 😃 > > A host-specific initrd / command line is needed today for: > > * features needing optional dracut modules (initrd rebuild needed to > enable them). > * configuration / secrets baked into the initrd (booting from iscsi > for example). > * configuration being specified on the kernel command line. > ** root filesystem being the most important one. > [https://systemd.io/DISCOVERABLE_PARTITIONS/ Discoverable partitions] > allow to remove this. > > Phase 1 goals (high priority): > > * Ship a unified kernel image as (optional) kernel sub-rpm. Users can > opt-in to use that kernel by installing the sub-rpm. Initial focus is > on booting virtual machines where we have a relatively small and well > defined set of drivers / features needed. Supporting modern physical > machines with standard setup (i.e. boot from local sata/nvme storage) > too should be easy. > * Update kernel install scripts so unified kernels are installed and > updated properly. > * Add bootloader support for unified kernel images. Add > [https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images > unified kernel bls support] to grub2, or support using systemd-boot, > or both. > > Phase 1 goals (lower priority, might move to Phase 2): > > * Add proper discoverable partitions support to installers (anaconda, > image builder, ...). > ** Temporary workaround possible: set types using sfdisk in %post script. > ** When using btrfs: configure 'root' subvolume as default volume. > * Add proper systemd-boot support to installers. > ** Temporary workaround possible: run 'bootctl install' in %post script. > * Better measurement and remote attestation support. > ** store kernel + initrd hashes somewhere (kernel-hashes.rpm ?) to > allow pre-calculate TPM PCR values. > ** avoid using grub2 (measures every config file line executed which > is next to impossible to pre-calculate). > * Switch cloud images to use unified kernels. > > Phase 2/3 goals (longer-term stuff which is not realistic to complete for > F38). > > * Move away from using the kernel command line for configuration. > * Move away from storing secrets in the initrd. > * Handle dracut optional modules in a different way. > > systemd has some building blocks which can be used, although none of > them are used by fedora today. > [https://www.freedesktop.org/software/systemd/man/systemd-creds.html > systemd credentials] can be used for secrets (also for configuration). > The [https://www.freedesktop.org/software/systemd/man/systemd-stub.html > unified kernel stub] can load credentials from the ESP. > > The unified kernel stub can also load > [https://www.freedesktop.org/software/systemd/man/systemd-sysext.html > extensions] from the ESP, which can possibly be used to replace > optional dracut modules. > > == Feedback == > > > == Benefit to Fedora == > * Better secure boot support (specifically the initrd is covered by > the signature). > * Better confidential computing support (measurements are much more > useful if we know what hashes to expect for the initrd). > * More robust boot process (generating the initrd on the installed > system is fragile, root cause for kernel bugs reported is simply a > broken initrd sometimes). > > == Scope == > * Proposal owners: > ** Update kernel build to create unified kernel sub-package. > *** part one: [https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2179 > PR#2179] > *** part two: (wip) > [
Re: Self Introduction: Hussein K.
Hi I'd like to mentor Hussein (FAS: blinxen) in learning to become a packager. He is a work colleague of mine. In particular, he's helping me getting libimagequant updated, which some time ago was ported to rust. As such, I'd like to add him as a co-maintainer of libimagequant and help him getting the new dependencies reviewed. Is anyone willing to sponsor Hussein? Thanks Sandro On 16.12.22 15:57, Sandro Mani wrote: Welcome! On 16.12.22 15:15, h-k...@hotmail.com wrote: Hello everyone This mail should serve as my self introduction to the devel community. I am a (soon to be) computer science graduate, that has been working in the Linux / open source world for about 6 years. I first started working as a python developer in the GIS (geographic information system) domain. After some time I also began to perform some system administration tasks. And before I knew I started to do a bit of everything. So to describe my current work, I do - Python development - System administration - Kubernetes administration (or whatever you want to call it) - A little bit of javascript - Devops (Automatic deployments via CI / CD pipelines, mainly using Gitlab CI) Oh, I also picked up rust a couple years ago and have been using it for Uni and private projects. Now the reason for why I want to get more involved in the Fedora package maintainer community is because I want to get a better understanding on how applications are packaged and distributed to end-users in a secure and stable manner. And from my experience, the best way to learn, is to get your hands dirty. Naturally, I also want to give back to the community, that has doing amazing work at developing Fedora and keeping everything working, and I want to become a part of it. In the last week, I have been reading a lot of documentation on RPM packaging and I have created my first package. I am currently looking for a sponsor to help me with my first package review: https://bugzilla.redhat.com/show_bug.cgi?id=2154124 This concludes my introduction and I hope this was not too much to read :D Best wishes Hussein K. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Tue, Dec 20, 2022 at 10:22:03AM -0500, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1 It's great to see this happening! > Phase 1 goals (high priority): > > * Ship a unified kernel image as (optional) kernel sub-rpm. Users can > opt-in to use that kernel by installing the sub-rpm. Initial focus is > on booting virtual machines where we have a relatively small and well > defined set of drivers / features needed. Supporting modern physical > machines with standard setup (i.e. boot from local sata/nvme storage) > too should be easy. > * Update kernel install scripts so unified kernels are installed and > updated properly. > * Add bootloader support for unified kernel images. Add > [https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images > unified kernel bls support] to grub2, or support using systemd-boot, > or both. > > Phase 1 goals (lower priority, might move to Phase 2): > > * Add proper discoverable partitions support to installers (anaconda, > image builder, ...). > ** Temporary workaround possible: set types using sfdisk in %post script. > ** When using btrfs: configure 'root' subvolume as default volume. > * Add proper systemd-boot support to installers. > ** Temporary workaround possible: run 'bootctl install' in %post script. > * Better measurement and remote attestation support. > ** store kernel + initrd hashes somewhere (kernel-hashes.rpm ?) to > allow pre-calculate TPM PCR values. > ** avoid using grub2 (measures every config file line executed which > is next to impossible to pre-calculate). > * Switch cloud images to use unified kernels. With my FESCo hat on, I immediately have the following comment: please narrow down the scope to things that we can actually approve for F38. E.g. the parts related to replacing grub2 by sd-boot are IMHO not realistic for F38 (*). And if we use grub2, then also the pre-calculation of TPM PCR values is not realistic, since they are too volatile with grub2... I think that those are all very interesting research tangents, but the stuff that gets a stamp of approval as a Fedora Change needs to be down-to-earth and users-know-what-to-expect and you-can-pretty-much-figure-out-how-things-will-look-from-the-change-description. (*) Or if that is actually the plan, please specify *where* sd-boot would be supported. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Tue, 20 Dec 2022 10:22:03 -0500 Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1 > > 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 == > Add support for unified kernels images to Fedora. > > == Owner == > * Name: [[User:kraxel| Gerd Hoffmann]] > * Email: kra...@redhat.com > > > == Detailed Description == > The goal is to move away from initrd images being generated on the > installed machine. They are generated while building the kernel > package instead, then shipped as part of a unified kernel image. > > A unified kernel image is an all-in-one efi binary containing kernel, > initrd, cmdline and signature. The secure boot signature covers > everything, specifically the initrd is included which is not the case > when the initrd gets loaded as separate file from /boot. What platforms are going to be affected? Is it x86-64 only or does it include aarch64 (as it's also using UEFI)? Are ppc64le and s390x out of the current scope? Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1 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 == Add support for unified kernels images to Fedora. == Owner == * Name: [[User:kraxel| Gerd Hoffmann]] * Email: kra...@redhat.com == Detailed Description == The goal is to move away from initrd images being generated on the installed machine. They are generated while building the kernel package instead, then shipped as part of a unified kernel image. A unified kernel image is an all-in-one efi binary containing kernel, initrd, cmdline and signature. The secure boot signature covers everything, specifically the initrd is included which is not the case when the initrd gets loaded as separate file from /boot. Main motivation for this move is to make the distro more robust and more secure. Switching the whole distro over to unified kernels quickly is not realistic though. Too many features are depending on the current workflow with a host-specific initrd (and host-specific kernel command line), which is fundamentally incompatible with unified kernels where everybody will have the same initrd and command line. Thats why there is 'Phase 1' in title, so we can have more Phases in future releases 😃 A host-specific initrd / command line is needed today for: * features needing optional dracut modules (initrd rebuild needed to enable them). * configuration / secrets baked into the initrd (booting from iscsi for example). * configuration being specified on the kernel command line. ** root filesystem being the most important one. [https://systemd.io/DISCOVERABLE_PARTITIONS/ Discoverable partitions] allow to remove this. Phase 1 goals (high priority): * Ship a unified kernel image as (optional) kernel sub-rpm. Users can opt-in to use that kernel by installing the sub-rpm. Initial focus is on booting virtual machines where we have a relatively small and well defined set of drivers / features needed. Supporting modern physical machines with standard setup (i.e. boot from local sata/nvme storage) too should be easy. * Update kernel install scripts so unified kernels are installed and updated properly. * Add bootloader support for unified kernel images. Add [https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images unified kernel bls support] to grub2, or support using systemd-boot, or both. Phase 1 goals (lower priority, might move to Phase 2): * Add proper discoverable partitions support to installers (anaconda, image builder, ...). ** Temporary workaround possible: set types using sfdisk in %post script. ** When using btrfs: configure 'root' subvolume as default volume. * Add proper systemd-boot support to installers. ** Temporary workaround possible: run 'bootctl install' in %post script. * Better measurement and remote attestation support. ** store kernel + initrd hashes somewhere (kernel-hashes.rpm ?) to allow pre-calculate TPM PCR values. ** avoid using grub2 (measures every config file line executed which is next to impossible to pre-calculate). * Switch cloud images to use unified kernels. Phase 2/3 goals (longer-term stuff which is not realistic to complete for F38). * Move away from using the kernel command line for configuration. * Move away from storing secrets in the initrd. * Handle dracut optional modules in a different way. systemd has some building blocks which can be used, although none of them are used by fedora today. [https://www.freedesktop.org/software/systemd/man/systemd-creds.html systemd credentials] can be used for secrets (also for configuration). The [https://www.freedesktop.org/software/systemd/man/systemd-stub.html unified kernel stub] can load credentials from the ESP. The unified kernel stub can also load [https://www.freedesktop.org/software/systemd/man/systemd-sysext.html extensions] from the ESP, which can possibly be used to replace optional dracut modules. == Feedback == == Benefit to Fedora == * Better secure boot support (specifically the initrd is covered by the signature). * Better confidential computing support (measurements are much more useful if we know what hashes to expect for the initrd). * More robust boot process (generating the initrd on the installed system is fragile, root cause for kernel bugs reported is simply a broken initrd sometimes). == Scope == * Proposal owners: ** Update kernel build to create unified kernel sub-package. *** part one: [https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2179 PR#2179] *** part two: (wip) [https://gitlab.com/kraxel/kernel-ark/-/commits/unified/ https://gitlab.com/kraxel/kernel-ark/-/commits/unified/] * Other developers: ** grub2: add unified kernel support *** wip code at [https://github.com/osteffenrh/grub2/ https://github.com/osteffenrh/grub2/] **
Re: GCC Fedora - relocation truncated to fit: R_X86_64_32S against `.rodata'
On Tue, Dec 20, 2022 at 02:49:48PM +0100, Florian Weimer wrote: > * Daniel P. Berrangé: > > > One notable thing is Ubuntu's use of --enable-default-pie. Some Google > > links also suggested -fPIC as a possible solution to my error, so I > > tried modifying the build system to add -fPIC to CFLAGS/LDFLAGS, but > > that merely gave me a differrent set of errors :-( > > Have you tried building with -fPIE? Why jump straight to -fPIC? I have not tried -fPIE, I just blindly went to -fPIC out of habit. > With -fPIE, the mapping address does not matter to the compiler (so no > absolute R_X86_64_32S relocations), and external calls should stop using > the GOT, too (so no more relaxation issues). Thanks for explaining, I've now confirmed that if I get -fPIE added in the right places, it successfully builds. With regards, Daniel -- |: 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 :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: GCC Fedora - relocation truncated to fit: R_X86_64_32S against `.rodata'
* Daniel P. Berrangé: > One notable thing is Ubuntu's use of --enable-default-pie. Some Google > links also suggested -fPIC as a possible solution to my error, so I > tried modifying the build system to add -fPIC to CFLAGS/LDFLAGS, but > that merely gave me a differrent set of errors :-( Have you tried building with -fPIE? Why jump straight to -fPIC? With -fPIE, the mapping address does not matter to the compiler (so no absolute R_X86_64_32S relocations), and external calls should stop using the GOT, too (so no more relaxation issues). Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: "Failed to set unit properties ..." during update
> Am 20.12.2022 um 09:37 schrieb Samuel Sieb : > > On 12/20/22 00:12, Peter Boy wrote: >> Yesterdays update showed a warning in logwatch of a Fedora Server instance >> (F36, plain standard installation, nothing fancy, just httpd and a >> systems-container): >> - dnf-rpm Begin >> Packages Updated: >> fedora-release-36-20.noarch -> fedora-release-36-21.noarch >> fedora-release-common-36-20.noarch -> fedora-release-common-36-21.noarch >> fedora-release-identity-basic-36-20.noarch -> >> fedora-release-identity-basic-36-21.noarch >> iputils-20211215-2.fc36.x86_64 -> iputils-20221126-1.fc36.x86_64 >> libtasn1-4.18.0-2.fc36.x86_64 -> libtasn1-4.19.0-1.fc36.x86_64 >> perl-Date-Manip-6.89-1.fc36.noarch -> perl-Date-Manip-6.90-1.fc36.noarch >> Information Messages: >> Failed to set unit properties on rdisc.service: Unit rdisc.service not >> found.: 1 Times(s) >> -- dnf-rpm End >> Last time a got such a message (regarding another service it I remember >> correctly) the system didn’t boot anymore. >> I found an old, closed EOL bugzilla entry >> (https://bugzilla.redhat.com/show_bug.cgi?id=1820285). But here that service >> is obviously not installed but now missed. The system worked without issues >> until now. And it still works. >> Any advice how to proceed? > > The rdisc.service was removed between those versions, so you can ignore that > message. Thanks for the info. -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST (UTC+2) Fedora Server Edition Working Group member Fedora docs team contributor Java developer and enthusiast ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)
On Tue, Dec 20, 2022 at 2:16 PM Vít Ondruch wrote: > Good to know. Thx. Please tell me that part of the plan is renaming dnf5 > => dnf and I'll shut up. > I second to this. While it makes sense to temporarily introduce a parallel installable dnf5 to enable easier early testing, I think dnf5 should get renamed to dnf when it's made the default. Anything else is just super confusing. -- Kalev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)
Dne 19. 12. 22 v 17:50 Jaroslav Mracek napsal(a): I am still very much against the `dnf5` package name and I have uneasy feelings reading (in my words) "`/usr/bin/dnf` symlink will change from `/usr/bin/dnf-3` to `/usr/bin/dnf5`". This name change is going to break so basic assumption such as `rpm -q dnf`. It won't really work even when `rpm -q dnf5` output was `dnf5-6.0.0-1.fc43.noarch`. Please give Fedora DNF version 5 instead of DNF5. Please reconsider the package name, especially when the "Obsolete dnf package by dnf5" is still part of the plan. There is still time to update the proposal. I am really sorry but I don't see a way how we can ship DNF5 as DNF package. The reason is quite simple. We already ship DNF5 in Fedora 38 as DNF5. Please don't use this argument. I was objecting introducing dnf5 package at the time it was reviewed: https://bugzilla.redhat.com/show_bug.cgi?id=2120661#c14 Now the existence of dnf5 is the reason why we can't do something? In Fedora 38 we need parallel installability with DNF and we cannot rename DNF as something else. I don't think you focus on the right thing. Parallel installabilility is not useful for anything except testing, mainly because the history gets broken with all the side effects. I understand that the upgrade needs to break something to improve thins for the long term, so I accept this breakage. But just one time. I can't imagine using DNF and DNF5 in parallel long term for anything useful. I also remember RHEL8 where we ship DNF as YUM. And DNF is very similar to YUM - both are Python based tool. Anyway in RHEL9 the same tool is shipped as DNF, because it creates a confusion. And I don't want to experience the same issue twice. I understand that the name change is always not nice, but keeping the same name for a different tool is worse. I was pointing this elsewhere. But if you really learned from YUM => DNF, then you would never mentioned DNF5, but DNF version 5. There would never be dnf5-5.0.1-1.fc38 package, but dnf-5.0.1-1.fc38. It seems to me that you are saying something while doing something completely different. This is confusing to me. BTW it would also help if you sketched out what is the timeline and process to deprecate DNF 4.x. I have a plan to open a system wide change to remove DNF for Fedora 40. Good to know. Thx. Please tell me that part of the plan is renaming dnf5 => dnf and I'll shut up. Vít OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: GCC Fedora - relocation truncated to fit: R_X86_64_32S against `.rodata'
On Tue, Dec 20, 2022 at 01:49:00PM +0100, Jakub Jelinek wrote:
> On Tue, Dec 20, 2022 at 12:12:42PM +, Daniel P. Berrangé wrote:
> > For KVM AMD SEV-SNP virtualization we're trying to get SVSM guest
> > firmware built on Fedora.
> >
> > https://github.com/svsm-vtpm/linux-svsm
> >
> > It builds successfully on Ubuntu 22.04 (gcc 11.3.0) which is what upstream
> > uses as their primary dev platform. On Fedora 37 (gcc 12.2.1) though, we're
> > getting errors at the final link stage. To eliminate version as a factor,
> > I also tried Fedora 35 with gcc 11.3.1 and got the same errors:
> >
> > gcc -m64 -nostdlib -Wl,-Tsrc/start/svsm.lds -Wl,--build-id=none -o
> > svsm.bin.elf src/start/start.o
> > target/x86_64-unknown-none/debug/liblinux_svsm.a -Wl,--start-group
> > ./external/build/lib/libtpm.a ./external/build/lib/libplatform.a
> > ./external/build/lib/libwolfssl.a ./external/build/lib/libcrt.a
> > ./external/build/lib/libm.a -Wl,--end-group
> > ./external/build/lib/libwolfssl.a(src_libwolfssl_la-sha256.o): in function
> > `Transform_Sha256':
> > sha256.c:(.text+0xba): relocation truncated to fit: R_X86_64_32 against
> > `.rodata'
> > ./external/build/lib/libwolfssl.a(src_libwolfssl_la-aes.o): in function
> > `wc_AesEncrypt':
> > aes.c:(.text+0x50): relocation truncated to fit: R_X86_64_32S against
> > `.rodata'
> > aes.c:(.text+0x68): relocation truncated to fit: R_X86_64_32S against
> > `.rodata'
> > aes.c:(.text+0x7e): relocation truncated to fit: R_X86_64_32S against
> > `.rodata'
> > aes.c:(.text+0x8c): relocation truncated to fit: R_X86_64_32S against
> > `.rodata'
> > aes.c:(.text+0x9e): relocation truncated to fit: R_X86_64_32S against
> > `.rodata'
> > aes.c:(.text+0xa9): relocation truncated to fit: R_X86_64_32S against
> > `.rodata'
> > aes.c:(.text+0xc5): relocation truncated to fit: R_X86_64_32S against
> > `.rodata'
> > aes.c:(.text+0xd3): relocation truncated to fit: R_X86_64_32S against
> > `.rodata'
> > aes.c:(.text+0xe9): relocation truncated to fit: R_X86_64_32S against
> > `.rodata'
> > aes.c:(.text+0xf8): additional relocation overflows omitted from the output
> > collect2: error: ld returned 1 exit status
> > make: *** [Makefile:54: svsm.bin.elf] Error 1
>
> That would mean either that your text + data segment are larger than 2GB, or
> src/start/svsm.lds you are using places the sections somewhere high in the
> address space, incompatible with the x86-64 default -mcmodel=small.
> Ubuntu defaults to -fpie -pie like we use in Fedora when hardening isn't
> disabled through specs from redhat-rpm-config, so it uses a different
> code model (small pic).
> You can build stuff with -fpie and link with -pie if you want, or
> -mcmodel=medium or -mcmodel=large etc., depends really on what
> src/start/svsm.lds
> is doing and how large the binary is.
> As documented:
> '-mcmodel=small'
> Generate code for the small code model: the program and its symbols
> must be linked in the lower 2 GB of the address space. Pointers
> are 64 bits. Programs can be statically or dynamically linked.
> This is the default code model.
>
> '-mcmodel=medium'
> Generate code for the medium model: the program is linked in the
> lower 2 GB of the address space. Small symbols are also placed
> there. Symbols with sizes larger than '-mlarge-data-threshold' are
> put into large data or BSS sections and can be located above 2GB.
> Programs can be statically or dynamically linked.
>
> '-mcmodel=large'
> Generate code for the large model. This model makes no assumptions
> about addresses and sizes of sections.
> etc.
The linker script has:
SECTIONS
{
. = SVSM_GPA_LDS;
and
#ifndef SVSM_GPA_LDS
#define SVSM_GPA_LDS0x80
#endif /* SVSM_GPA_LDS */
So, this is indeed incompatible with both small and medium code models,
so everything that is linked into that binary should be compiled with
-mcmodel=large and pay the code performance price for that.
Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: GCC Fedora - relocation truncated to fit: R_X86_64_32S against `.rodata'
On Tue, Dec 20, 2022 at 12:12:42PM +, Daniel P. Berrangé wrote: > For KVM AMD SEV-SNP virtualization we're trying to get SVSM guest > firmware built on Fedora. > > https://github.com/svsm-vtpm/linux-svsm > > It builds successfully on Ubuntu 22.04 (gcc 11.3.0) which is what upstream > uses as their primary dev platform. On Fedora 37 (gcc 12.2.1) though, we're > getting errors at the final link stage. To eliminate version as a factor, > I also tried Fedora 35 with gcc 11.3.1 and got the same errors: > > gcc -m64 -nostdlib -Wl,-Tsrc/start/svsm.lds -Wl,--build-id=none -o > svsm.bin.elf src/start/start.o > target/x86_64-unknown-none/debug/liblinux_svsm.a -Wl,--start-group > ./external/build/lib/libtpm.a ./external/build/lib/libplatform.a > ./external/build/lib/libwolfssl.a ./external/build/lib/libcrt.a > ./external/build/lib/libm.a -Wl,--end-group > ./external/build/lib/libwolfssl.a(src_libwolfssl_la-sha256.o): in function > `Transform_Sha256': > sha256.c:(.text+0xba): relocation truncated to fit: R_X86_64_32 against > `.rodata' > ./external/build/lib/libwolfssl.a(src_libwolfssl_la-aes.o): in function > `wc_AesEncrypt': > aes.c:(.text+0x50): relocation truncated to fit: R_X86_64_32S against > `.rodata' > aes.c:(.text+0x68): relocation truncated to fit: R_X86_64_32S against > `.rodata' > aes.c:(.text+0x7e): relocation truncated to fit: R_X86_64_32S against > `.rodata' > aes.c:(.text+0x8c): relocation truncated to fit: R_X86_64_32S against > `.rodata' > aes.c:(.text+0x9e): relocation truncated to fit: R_X86_64_32S against > `.rodata' > aes.c:(.text+0xa9): relocation truncated to fit: R_X86_64_32S against > `.rodata' > aes.c:(.text+0xc5): relocation truncated to fit: R_X86_64_32S against > `.rodata' > aes.c:(.text+0xd3): relocation truncated to fit: R_X86_64_32S against > `.rodata' > aes.c:(.text+0xe9): relocation truncated to fit: R_X86_64_32S against > `.rodata' > aes.c:(.text+0xf8): additional relocation overflows omitted from the output > collect2: error: ld returned 1 exit status > make: *** [Makefile:54: svsm.bin.elf] Error 1 That would mean either that your text + data segment are larger than 2GB, or src/start/svsm.lds you are using places the sections somewhere high in the address space, incompatible with the x86-64 default -mcmodel=small. Ubuntu defaults to -fpie -pie like we use in Fedora when hardening isn't disabled through specs from redhat-rpm-config, so it uses a different code model (small pic). You can build stuff with -fpie and link with -pie if you want, or -mcmodel=medium or -mcmodel=large etc., depends really on what src/start/svsm.lds is doing and how large the binary is. As documented: '-mcmodel=small' Generate code for the small code model: the program and its symbols must be linked in the lower 2 GB of the address space. Pointers are 64 bits. Programs can be statically or dynamically linked. This is the default code model. '-mcmodel=medium' Generate code for the medium model: the program is linked in the lower 2 GB of the address space. Small symbols are also placed there. Symbols with sizes larger than '-mlarge-data-threshold' are put into large data or BSS sections and can be located above 2GB. Programs can be statically or dynamically linked. '-mcmodel=large' Generate code for the large model. This model makes no assumptions about addresses and sizes of sections. etc. Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On Tue, Dec 20, 2022 at 1:28 PM Miro Hrončok wrote: > > On 19. 12. 22 18:47, Barry Scott wrote: > > > > > >> On 19 Dec 2022, at 17:40, Ben Cotton wrote: > >> > >> On Mon, Dec 19, 2022 at 12:36 PM Barry wrote: > >>> > >>> Why is pysvn on the list? I the pysvn maintainer and i am active. > >>> I am also the upstream maintainer. > >> > >> The "main admin" is orphan. You should be able to go to > >> https://src.fedoraproject.org/rpms/pysvn and click the "Take" button > >> on the left-hand side. (This is an unfortunate side-effect of how > >> dist-git works). > > > > Taken and I'm the bugzilla contact as well. > > > > Does "main admin" being "orphan" go away when background processes catch up > > with the changes I just made? > > It should. In my experience, pressing the "Take" button doesn't refresh all parts of the UI automatically, but after doing a page refresh with F5 / Ctrl-R, the UI shows the correct state. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: GCC Fedora - relocation truncated to fit: R_X86_64_32S against `.rodata'
On Tue, 2022-12-20 at 12:12 +, Daniel P. Berrangé wrote: > gcc -m64 -nostdlib -Wl,-Tsrc/start/svsm.lds -Wl,--build-id=none -o > svsm.bin.elf src/start/start.o target/x86_64-unknown- > none/debug/liblinux_svsm.a -Wl,--start-group > ./external/build/lib/libtpm.a ./external/build/lib/libplatform.a > ./external/build/lib/libwolfssl.a ./external/build/lib/libcrt.a > ./external/build/lib/libm.a -Wl,--end-group https://stackoverflow.com/questions/19768267/relocation-r-x86-64-32s-against-linking-error/38579792#38579792 -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On 19. 12. 22 18:47, Barry Scott wrote: On 19 Dec 2022, at 17:40, Ben Cotton wrote: On Mon, Dec 19, 2022 at 12:36 PM Barry wrote: Why is pysvn on the list? I the pysvn maintainer and i am active. I am also the upstream maintainer. The "main admin" is orphan. You should be able to go to https://src.fedoraproject.org/rpms/pysvn and click the "Take" button on the left-hand side. (This is an unfortunate side-effect of how dist-git works). Taken and I'm the bugzilla contact as well. Does "main admin" being "orphan" go away when background processes catch up with the changes I just made? It should. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
GCC Fedora - relocation truncated to fit: R_X86_64_32S against `.rodata'
For KVM AMD SEV-SNP virtualization we're trying to get SVSM guest firmware built on Fedora. https://github.com/svsm-vtpm/linux-svsm It builds successfully on Ubuntu 22.04 (gcc 11.3.0) which is what upstream uses as their primary dev platform. On Fedora 37 (gcc 12.2.1) though, we're getting errors at the final link stage. To eliminate version as a factor, I also tried Fedora 35 with gcc 11.3.1 and got the same errors: gcc -m64 -nostdlib -Wl,-Tsrc/start/svsm.lds -Wl,--build-id=none -o svsm.bin.elf src/start/start.o target/x86_64-unknown-none/debug/liblinux_svsm.a -Wl,--start-group ./external/build/lib/libtpm.a ./external/build/lib/libplatform.a ./external/build/lib/libwolfssl.a ./external/build/lib/libcrt.a ./external/build/lib/libm.a -Wl,--end-group ./external/build/lib/libwolfssl.a(src_libwolfssl_la-sha256.o): in function `Transform_Sha256': sha256.c:(.text+0xba): relocation truncated to fit: R_X86_64_32 against `.rodata' ./external/build/lib/libwolfssl.a(src_libwolfssl_la-aes.o): in function `wc_AesEncrypt': aes.c:(.text+0x50): relocation truncated to fit: R_X86_64_32S against `.rodata' aes.c:(.text+0x68): relocation truncated to fit: R_X86_64_32S against `.rodata' aes.c:(.text+0x7e): relocation truncated to fit: R_X86_64_32S against `.rodata' aes.c:(.text+0x8c): relocation truncated to fit: R_X86_64_32S against `.rodata' aes.c:(.text+0x9e): relocation truncated to fit: R_X86_64_32S against `.rodata' aes.c:(.text+0xa9): relocation truncated to fit: R_X86_64_32S against `.rodata' aes.c:(.text+0xc5): relocation truncated to fit: R_X86_64_32S against `.rodata' aes.c:(.text+0xd3): relocation truncated to fit: R_X86_64_32S against `.rodata' aes.c:(.text+0xe9): relocation truncated to fit: R_X86_64_32S against `.rodata' aes.c:(.text+0xf8): additional relocation overflows omitted from the output collect2: error: ld returned 1 exit status make: *** [Makefile:54: svsm.bin.elf] Error 1 I'm guessing there must be some difference in GCC defaults that is affecting things The Ubuntu build specs are # gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.3.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-11-xKiWfi/gcc-11-11.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-xKiWfi/gcc-11-11.3.0/debian/tmp-gcn/usr --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04) While Fedora build specs are $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/12/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --enable-libstdcxx-backtrace --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-12.2.1-20221121/obj-x86_64-redhat-linux/isl-install --enable-offload-targets=nvptx-none --without-cuda-driver --enable-offload-defaulted --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux --with-build-config=bootstrap-lto --enable-link-serialization=1 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.1 20221121 (Red Hat 12.2.1-4) (GCC) One notable thing is Ubuntu's use of --enable-default-pie.
Re: Orphaned packages looking for new maintainers
On Mon, Dec 19, 2022 at 6:00 PM Miro Hrončok wrote: > perl-POE-Component-Client-Pingorphan 3 weeks > ago > Taking. M. -- Michal Josef Špaček ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
Hello Miro, > tito frostyx, maxamillion, orphan 3 weeks ago Taking On Tue, Dec 20, 2022 at 12:30 AM Emmanuel Seyman wrote: > > * Miro Hrončok [19/12/2022 16:43] : > > > > perl-Mail-Procmailorphan 0 weeks > > ago > > Taken. > > Emmanuel > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Testing of the New Staging Deployment of MDAPI
Hi folks, I hope you are doing well. I write this to let you know that I have been working on the MDAPI project under Pierre-Yves Chibon's guidance for some time now for 1. Refactoring the code 2. Implementing code quality standards 3. Adding more comprehensive tests 4. Implementing a CLI wrapper And other major changes The codebase functionality remains the same in this rewrite for users, but I have made attempts to ensure that it becomes relatively easier for the community members to be able to contribute to the project with the addition of documentation, enhancements in code readability and other miscellaneous changes that help improve the contributor quality of life. Once the changes were completed, I moved the repository from my personal GitHub namespace (now archived)[1] over to Fedora Infra's GitHub namespace[2] and deployed it on the Fedora's staging environment[3], with David Kirwan's assistance. Please take it for a spin and test it out so that we can fix as many issues as we can before we deploy it on the production environment. Happy holidays! :) Index 1. https://github.com/t0xic0der/mdapi 2. https://github.com/fedora-infra/mdapi 3. https://mdapi.stg.fedoraproject.org/ Regards, Akashdeep Dhar (he/him), Objective Representative, Fedora Council Red Hat Community Platform Engineering t0xic0...@fedoraproject.org akashd...@redhat.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: "Failed to set unit properties ..." during update
On 12/20/22 00:12, Peter Boy wrote: Yesterdays update showed a warning in logwatch of a Fedora Server instance (F36, plain standard installation, nothing fancy, just httpd and a systems-container): - dnf-rpm Begin Packages Updated: fedora-release-36-20.noarch -> fedora-release-36-21.noarch fedora-release-common-36-20.noarch -> fedora-release-common-36-21.noarch fedora-release-identity-basic-36-20.noarch -> fedora-release-identity-basic-36-21.noarch iputils-20211215-2.fc36.x86_64 -> iputils-20221126-1.fc36.x86_64 libtasn1-4.18.0-2.fc36.x86_64 -> libtasn1-4.19.0-1.fc36.x86_64 perl-Date-Manip-6.89-1.fc36.noarch -> perl-Date-Manip-6.90-1.fc36.noarch Information Messages: Failed to set unit properties on rdisc.service: Unit rdisc.service not found.: 1 Times(s) -- dnf-rpm End Last time a got such a message (regarding another service it I remember correctly) the system didn’t boot anymore. I found an old, closed EOL bugzilla entry (https://bugzilla.redhat.com/show_bug.cgi?id=1820285). But here that service is obviously not installed but now missed. The system worked without issues until now. And it still works. Any advice how to proceed? The rdisc.service was removed between those versions, so you can ignore that message. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
"Failed to set unit properties ..." during update
Yesterdays update showed a warning in logwatch of a Fedora Server instance (F36, plain standard installation, nothing fancy, just httpd and a systems-container): - dnf-rpm Begin Packages Updated: fedora-release-36-20.noarch -> fedora-release-36-21.noarch fedora-release-common-36-20.noarch -> fedora-release-common-36-21.noarch fedora-release-identity-basic-36-20.noarch -> fedora-release-identity-basic-36-21.noarch iputils-20211215-2.fc36.x86_64 -> iputils-20221126-1.fc36.x86_64 libtasn1-4.18.0-2.fc36.x86_64 -> libtasn1-4.19.0-1.fc36.x86_64 perl-Date-Manip-6.89-1.fc36.noarch -> perl-Date-Manip-6.90-1.fc36.noarch Information Messages: Failed to set unit properties on rdisc.service: Unit rdisc.service not found.: 1 Times(s) -- dnf-rpm End Last time a got such a message (regarding another service it I remember correctly) the system didn’t boot anymore. I found an old, closed EOL bugzilla entry (https://bugzilla.redhat.com/show_bug.cgi?id=1820285). But here that service is obviously not installed but now missed. The system worked without issues until now. And it still works. Any advice how to proceed? Thanks ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
