Re: replace memtest86+ with pcmemtest, needs maintainer
On Fri, 2021-07-30 at 18:57 -0600, Chris Murphy wrote: > [Bug 1988142] memtest boot entry on Fedora install media does not work > since Fedora-Rawhide-20210728.n.3 > https://bugzilla.redhat.com/show_bug.cgi?id=1988142 > > This bug might be gcc, but also includes a note about the upstream > being kinda weak, possibly non-existent these days. > > Neal Gompa mentioned pcmemtest earlier this year > https://github.com/martinwhitaker/pcmemtest > > It would need a maintainer. Any takers? So while this is still being thrashed out, I proposed: https://pagure.io/fedora-comps/pull-request/676 which should remove memtest86+ and the menu entry for it from media for now. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
On 9/3/21 12:13 PM, Gordon Messmer wrote: Does Fedora GRUB also contain changes that might interfere with chainloading? I believe that some people are using it to chainload the Windows boot loader, but maybe it only works for binaries with signatures? # sbsign --key MOK.priv --cert MOK.pem /boot/pcmemtest.efi --output /boot/pcmemtest.efi.signed PE opt header too small (112 bytes) to contain a suitable data directory (need 152 bytes) That's.. interesting? ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
On 9/3/21 2:26 AM, Hans de Goede wrote: It might be interesting to try and using e.g. an EFI grub binary from Ubuntu with a: linux /pcmemtest.efi I created a UEFI VM running Debian 11 to try that out. It doesn't work there, but I'm seeing in consistent results. The first time around selecting that GRUB entry would crash the VM with an error logged*, but after shutting the VM off and then starting it again, that entry just causes the VM to reboot immediately. However, "chainloader /boot/pcmemtest.efi" does work in the Debian VM, and I'm told also under openSUSE (https://lists.gnu.org/archive/html/help-grub/2021-09/msg1.html) but not under Fedora. Does Fedora GRUB also contain changes that might interfere with chainloading? I believe that some people are using it to chainload the Windows boot loader, but maybe it only works for binaries with signatures? *: Log contains: KVM internal error. Suberror: 1 emulation failure EAX=80010033 EBX= ECX=c080 EDX= ESI=00088ffe EDI= EBP= ESP=00137100 EIP=0010027a EFL=00200086 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0018 00c09300 DPL=0 DS [-WA] CS =0010 00c09b00 DPL=0 CS32 [-RA] SS =0018 00c09300 DPL=0 DS [-WA] DS =0018 00c09300 DPL=0 DS [-WA] FS =0018 00c09300 DPL=0 DS [-WA] GS =0018 00c09300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS64-busy GDT= 10d0 0020 IDT= 3f573018 0fff CR0=80010033 CR2= CR3=0001 CR4=0668 DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER=0d00 Code=?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
Hi, On 8/30/21 9:35 PM, Gordon Messmer wrote: > On 8/30/21 12:08 PM, Hans de Goede wrote: >> >> I checked the entry on a Windows multiboot system and it does not have the >> "insmod chain" line, maybe droppint that helps? > > > Same result. GRUB returns immediately to its menu. I'm certain the path is > correct, because GRUB will report an error if it is wrong. So I took a quick look myself and I could not get this to work either, the EFI binary is weird and the talk of "Linux handoff protocol" in the README makes me think that the grub menu entry actually should look like this: linux /pcmemtest.efi I tried that, with Fedora's grub but it does not work either (the screen goes black IIRC). Still I believe this is how it is supposed to work, also because of this: [root@x1 ~]# file /boot/efi/EFI/fedora/pcmemtest.efi /boot/efi/EFI/fedora/pcmemtest.efi: Linux kernel x86 boot executable bzImage, version \353fHdrS\014\002, RW-rootFS, I believe this is not working with Fedora's EFI grub binaries because we patch grub to not use the handover protocol when running in EFI mode. The Linux x86_64 vmlinuz image actually has an EFI stub, so that it can be executed as an EFI executable without needing a bootloader at all. And AFAIK that stub actually works better / on more hw then letting grub do the BIOS oriented handover-protocol thingie on EFI. So the Fedora EFI grub is patched to treat a "linux" line as a chainload line (more or less) with the exception of doing some stuff to pass the cmdline + initrd. It might be interesting to try and using e.g. an EFI grub binary from Ubuntu with a: linux /pcmemtest.efi menu entry, to confirm my theory and after that it is probably best to reach out to pcmemtest's upstream about this. Regards, Hans p.s. Note that pcmemtest does not really seem to be a "proper" EFI app instead it just contains the bare essentials to run, but e.g. keyboard input does not work unless the BIOS compat module of the EFI is enabled, which now a days usually it is not. So I'm afraid that getting this ready will require a fair amount of work. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
On Mon, 2021-08-30 at 12:35 -0700, Gordon Messmer wrote:
> On 8/30/21 12:08 PM, Hans de Goede wrote:
> >
> > I checked the entry on a Windows multiboot system and it does not
> > have the
> > "insmod chain" line, maybe droppint that helps?
>
>
> Same result. GRUB returns immediately to its menu. I'm certain the
> path is correct, because GRUB will report an error if it is wrong.
Don't know about pcmemtest, but what I have dual booting for Windows
is:
menuentry 'Windows 10/7 (EFI)' --class windows --class os --unrestricted {
insmod part_gpt
insmod fat
set root='hd0,gpt4'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt4
--hint-efi=hd0,gpt4 --hint-baremetal=ahci0,gpt4 --hint='hd0,gpt4' CC13-F911
else
search --no-floppy --fs-uuid --set=root CC13-F911
fi
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
Regards
Frank
___
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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
On 8/30/21 12:08 PM, Hans de Goede wrote: I checked the entry on a Windows multiboot system and it does not have the "insmod chain" line, maybe droppint that helps? Same result. GRUB returns immediately to its menu. I'm certain the path is correct, because GRUB will report an error if it is wrong. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
Hi, On 8/30/21 7:11 PM, Gordon Messmer wrote: > On 8/30/21 12:20 AM, Hans de Goede wrote: >> For the grub bit I think you just need a menu entry with a chainloader >> line in there, similar to how booting Windows in a multi-boot setup works. > > > Among other things, I've tried > > insmod chain > chainloader //pcmemtest.efi > > When that menuentry is selected, GRUB2 will immediately return to its list. > I've never dual-booted Windows on a UEFI system, so I don't know if there's > more to it than that. I checked the entry on a Windows multiboot system and it does not have the "insmod chain" line, maybe droppint that helps? Regards, Hans ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
On 8/30/21 12:20 AM, Hans de Goede wrote: For the grub bit I think you just need a menu entry with a chainloader line in there, similar to how booting Windows in a multi-boot setup works. Among other things, I've tried insmod chain chainloader //pcmemtest.efi When that menuentry is selected, GRUB2 will immediately return to its list. I've never dual-booted Windows on a UEFI system, so I don't know if there's more to it than that. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
Hi, On 8/29/21 11:46 PM, Gordon Messmer wrote: > On 8/1/21 3:54 PM, Neal Gompa wrote: >> But that doesn't stop anyone from maintaining an unsigned version. > > > The documentation suggests that the UEFI binary can be loaded directly (which > I've done), or through the EFI handover protocol. I haven't done the latter > successfully yet. If I work out the correct GRUB invocation, I'll add > another helper and submit this for review. > > https://fedorapeople.org/cgit/gordonmessmer/public_git/pcmemtest-unsigned-x64.git/ > https://gordonmessmer.fedorapeople.org/pcmemtest-unsigned-x64/ Thank you for working on this. For the grub bit I think you just need a menu entry with a chainloader line in there, similar to how booting Windows in a multi-boot setup works. Regards, Hans ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
On 8/1/21 3:54 PM, Neal Gompa wrote: But that doesn't stop anyone from maintaining an unsigned version. The documentation suggests that the UEFI binary can be loaded directly (which I've done), or through the EFI handover protocol. I haven't done the latter successfully yet. If I work out the correct GRUB invocation, I'll add another helper and submit this for review. https://fedorapeople.org/cgit/gordonmessmer/public_git/pcmemtest-unsigned-x64.git/ https://gordonmessmer.fedorapeople.org/pcmemtest-unsigned-x64/ ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
Hello, On Sun, Aug 1, 2021 at 7:46 PM Chris Murphy wrote: [..] > 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 can confirm, in the last instances I had to deal with memory hardware corruption and I tried memtest86+, it didn't find any memory errors. Whereas, on the same hosts, memtester quickly found them. Best regards Georg ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
On 02/08/2021 08:56, Chris Murphy wrote: Does this apply to the current 5.31 beta? I guess it's also a bit beside the point, because any modern Intel and AMD processor also has UEFI firmware. In order to enable the legacy/CSM you have to disable UEFI Secure Boot which... it's not good to advise this. Tested with memtest86+-5.31-0.3.beta.fc34 on Intel Core i7 10700 - hangs on start. Tested on AMD Ryzen 7 5800X - it starts, works, then system hangs. Need to press Reset button. -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
On 02/08/2021 14:34, Nikolay Nikolov wrote: The memtest86+, included in the Fedora install media works. AMD Ryzen 9 5900X here, with 128 GB RAM. Unfortunately, it was recently removed from the install media. Intel Core i7 10700 - hangs on start in legacy mode even from the Fedora LiveUSB. -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
On 8/2/21 9:15 AM, Vitaly Zaitsev via devel wrote: On 02/08/2021 04:04, Chris Murphy wrote: I'm definitely not attached to keeping things the same. The bios memtest86+ is still these days installed to /boot but there hasn't been a menu entry for it for a very long time; in fact maybe it was only ever on netintall or dvd images? I can't remember that far back memtest86+ doesn't support UEFI. It only has a menu entry if the Legacy boot is used. Also memtest86+ doesn't support modern Intel and AMD processors. It will hang on start. The memtest86+, included in the Fedora install media works. AMD Ryzen 9 5900X here, with 128 GB RAM. Unfortunately, it was recently removed from the install media. The memtest86+, installed on your computer in Legacy boot mode and then added to the Grub boot menu, doesn't work and crashes on start on the same computer. That's why I install in UEFI mode, but keep my Fedora 33 install DVD+R disk around and boot it in Legacy mode to run memtest86+ when I need it. The fact that the OS is installed in UEFI mode doesn't matter. Nikolay ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
On Mon, Aug 2, 2021 at 12:15 AM Vitaly Zaitsev via devel wrote: > > On 02/08/2021 04:04, Chris Murphy wrote: > > I'm definitely not attached to keeping things the same. The bios > > memtest86+ is still these days installed to /boot but there hasn't > > been a menu entry for it for a very long time; in fact maybe it was > > only ever on netintall or dvd images? I can't remember that far back > > memtest86+ doesn't support UEFI. It only has a menu entry if the Legacy > boot is used. Yeah I mentioned that in the first post. > Also memtest86+ doesn't support modern Intel and AMD processors. It will > hang on start. Does this apply to the current 5.31 beta? I guess it's also a bit beside the point, because any modern Intel and AMD processor also has UEFI firmware. In order to enable the legacy/CSM you have to disable UEFI Secure Boot which... it's not good to advise this. -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
On 02/08/2021 04:04, Chris Murphy wrote: I'm definitely not attached to keeping things the same. The bios memtest86+ is still these days installed to /boot but there hasn't been a menu entry for it for a very long time; in fact maybe it was only ever on netintall or dvd images? I can't remember that far back memtest86+ doesn't support UEFI. It only has a menu entry if the Legacy boot is used. Also memtest86+ doesn't support modern Intel and AMD processors. It will hang on start. -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
On Sun, Aug 1, 2021 at 7:51 PM Steven A. Falco wrote: > > 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. > I'm definitely not attached to keeping things the same. The bios memtest86+ is still these days installed to /boot but there hasn't been a menu entry for it for a very long time; in fact maybe it was only ever on netintall or dvd images? I can't remember that far back :P I guess the gotcha with a single boot image, is it can be difficult to boot BIOS and UEFI from a USB stick (treated by firmware as a hard drive) and from optical. We're doing this today with the common Fedora desktop and server ISO images, created by xorriso which has an ISO hybrid option that bakes into the ISO 9660 image, two El Torito images. One for UEFI and one for BIOS. That's because, hilariously, natively booting ISO 9660 or UDF is not a thing that was added to the UEFI spec. But if this image works consistently, and we don't sneeze, it should be OK? What's this... I'm now hearing a virtual convo about an S word among the Adam Williamson and Kamil Paral who live in my head... -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
On 8/1/21 8:46 PM, Chris Murphy wrote: On Sun, Aug 1, 2021 at 4:55 PM Neal Gompa wrote: On Sun, Aug 1, 2021 at 6:49 PM Gordon Messmer 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@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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
On Sun, Aug 1, 2021 at 4:55 PM Neal Gompa wrote: > > On Sun, Aug 1, 2021 at 6:49 PM Gordon Messmer > 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@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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
On Sun, Aug 1, 2021 at 6:49 PM Gordon Messmer 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. -- 真実はいつも一つ！/ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
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. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
On 31/07/2021 19:47, Chris Murphy wrote: I'm referring to memtest86+ not memtest86 Memtest86+ is a fork of the opensource version of memtest86. -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
On Sat, Jul 31, 2021 at 1:28 AM Vitaly Zaitsev via devel wrote: > > On 31/07/2021 02:57, Chris Murphy wrote: > > This bug might be gcc, but also includes a note about the upstream > > being kinda weak, possibly non-existent these days. > > They just closed the sources. Memtest86 is a commercial product now. It > has full UEFI support, etc. I'm referring to memtest86+ not memtest86 http://www.memtest.org https://koji.fedoraproject.org/koji/packageinfo?packageID=829 It's a bit confusing. https://en.wikipedia.org/wiki/Memtest86 memtest86 is proprietary and the latest versions are uefi only. memtest86+ uses a free license and is bios only. pcmemtest supports both uefi and bios, and also has a free license. -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
On 31/07/2021 12:37, Alexander Ploumistos wrote: Just to be sure, you are talking about Memtest86, not Memtest86+, right? Yes. From the official website: Based on the well-known original memtest86 written by Chris Brady, memtest86+ is a port by some members of the x86-secret team, now working at www.canardpc.com. Our goal is to provide an up-to-date and completly reliable version of this software tool aimed at memory failures detection. Memtest86+ was, is and will always be a free, open-source software. The original Memtest86 is now handled by PassMark® Software Pty Ltd. Memtest86+ was a fork of the opensource version of memtest86. Now memtest86 is a commercial product. -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
Hi Vitaly, On Sat, Jul 31, 2021 at 10:28 AM Vitaly Zaitsev via devel wrote: > > They just closed the sources. Memtest86 is a commercial product now. It > has full UEFI support, etc. Just to be sure, you are talking about Memtest86, not Memtest86+, right? ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
El sáb, 31 jul 2021 a las 2:58, Chris Murphy () escribió: > Neal Gompa mentioned pcmemtest earlier this year > https://github.com/martinwhitaker/pcmemtest > > It would need a maintainer. Any takers? > > Hi, I'm not interested in owning the package, but I've created a test build because I want to play with it. Just in case someone finds this util, I've created this copr: https://copr.fedorainfracloud.org/coprs/jorti/pcmemtest/ https://copr-dist-git.fedorainfracloud.org/cgit/jorti/pcmemtest/pcmemtest.git/tree/pcmemtest.spec Best regards. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
On 31/07/2021 02:57, Chris Murphy wrote: This bug might be gcc, but also includes a note about the upstream being kinda weak, possibly non-existent these days. They just closed the sources. Memtest86 is a commercial product now. It has full UEFI support, etc. -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
replace memtest86+ with pcmemtest, needs maintainer
[Bug 1988142] memtest boot entry on Fedora install media does not work since Fedora-Rawhide-20210728.n.3 https://bugzilla.redhat.com/show_bug.cgi?id=1988142 This bug might be gcc, but also includes a note about the upstream being kinda weak, possibly non-existent these days. Neal Gompa mentioned pcmemtest earlier this year https://github.com/martinwhitaker/pcmemtest It would need a maintainer. Any takers? Fedora doesn't have a release criterion covering the memory tester, or really any option appearing in the install media's boot menu other than the one that launches the installer. But I think it's better to not ship a memory tester at all, than to ship a broken one (given the options). Memtest86+ is bios only, where pcmemtest can be compiled to run on either firmware type. If we want it to work with UEFI Secure Boot enabled, it'd need to be signed with Fedora's key (I think the same as the one used for GRUB and/or the kernel?). This would be in scope for Fedora 36, assuming the above bug can be easily fixed. But if that bug is hard to fix, and pcmemtest could be a drop-in replacement (i.e. bios only, just like now) maybe that's doable for Fedora 35, and better than having no memory tester. Chris Murphy -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
