On 8/1/21 8:46 PM, Chris Murphy wrote:
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.
After seeing this discussion I got curious, and I noticed that one can build an iso of pcmemtest that is directly bootable. No OS or additional bootloader needed.
So if someone needs to test their hardware, the easiest thing to do today would be to put the iso on a flash drive (or even a cdrom) and boot it from there.
Steve
_______________________________________________
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
