On Sun, Aug 1, 2021 at 4:55 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > On Sun, Aug 1, 2021 at 6:49 PM Gordon Messmer <gordon.messmer@xxxxxxxxx> wrote: > > > > On 7/30/21 5:57 PM, Chris Murphy wrote: > > > It would need a maintainer. Any takers? ... > > > If we want it to work with UEFI Secure Boot > > > enabled, it'd need to be signed with Fedora's key > > > > > > Does the signing requirement imply that the maintainer would need to be > > a Red Hat employee (or another trusted party)? > > > > I'm interested in contributing more than I do currently, but I'm not > > sure what the process of signing a bootable image looks like. If I'm in > > a position to do so, I'd be interested in acting as a maintainer or > > co-maintainer for the package. > > > > Unfortunately, yes. As far as I know, non-RH folks are not allowed to > do builds that are signed with the production Fedora secure boot key. > But that doesn't stop anyone from maintaining an unsigned version. > If there's a maintained unsigned version, it's more straightforward for a RH co-maintainer to put that version through the signing pipeline. While the issue of bad RAM is obviously an edge case, it's a top cause of file system corruption (at least on btrfs, mainly detected there because it's designed to detect such things in both metadata and data - but this kind of corruption still happens with any other file system). So it's quite a pernicious problem that I think we've (innocently) become a bit complacent about in the move to UEFI, not having a UEFI memory checker at all. We do have memtester in the repository, which is a user space memory tester. But I can't really assess whether it's better or worse than one that runs in the pre-boot environment. On the one hand, less memory is being tested (possibly quite a bit less) with a user space tester. But on the other hand, better memory testers find bad RAM faster. They aren't all equally effective at this. At least over in #btrfs land, we see evidence of bad RAM sourced corruption, and occasionally it's tedious to find it (neither memtest86 or memtest86+ finding it, but doing a bunch of compiles of the kernel with gcc does find it - almost like gcc is a good memory tester, however unintended, much like btrfs and probably also zfs). I guess we need some testers with known bad RAM lying around to give pcmemtest copr a whirl, see if it sniffs out the bad RAM in a reasonable amount of time. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
