Re: replace memtest86+ with pcmemtest, needs maintainer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux