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
Re: New memory tester application potentially to replace memtest86+: PCMemTest
* Florian Weimer: > * Neal Gompa: > >> None of this had to be this way. It is so by our own inaction, not by >> the action of Microsoft. > > I agree. No one but Microsoft stepped up and was willing to control the > key material. > > I still wish we went the way of documenting how to disable Secure Boot > in commonly used firmware implementations. Secure Boot does not offer > any benefit to a platform designed to be as malleable as Fedora is. I > tried to start that documentation, but I got the distinct impression it > was unwanted. > > Instead run-time disabling of Secure Boot support without reboot comes > and goes, particularly in downstream kernels. Kernel modules are such > an important diagnostic tool, and not everyone plans ahead and disables > Secure Boot in case they need to load kernel modules later. (“run-time disabling of kernel lockdown“ is more accurate—but of course if there's an off switch for this feature, lockdown isn't very effective in the first place.) >>> And for the record, my computer's UEFI firmware is so old that >>> "Secure Boot" cannot even be enabled at all, even if I wanted to. >> >> Meh. That means your computer was made before Microsoft started having >> vendors require UEFI firmware to include their keys for Windows >> certification (which was in 2006/2007). I'm surprised it still works. >> More power to you, I guess? > > Last time I checked this, the Microsoft keys required for Windows > certification were not those used to sign third-party binaries like the > Fedora shim (the “Microsoft Corporation Third Party Marketplace Root”). > You could see the difference in Hyper-V configurations, where the > default Secure Boot configuration cannot boot Fedora. > > Thanks, > Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ 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
Re: New memory tester application potentially to replace memtest86+: PCMemTest
* Neal Gompa: > None of this had to be this way. It is so by our own inaction, not by > the action of Microsoft. I agree. No one but Microsoft stepped up and was willing to control the key material. I still wish we went the way of documenting how to disable Secure Boot in commonly used firmware implementations. Secure Boot does not offer any benefit to a platform designed to be as malleable as Fedora is. I tried to start that documentation, but I got the distinct impression it was unwanted. Instead run-time disabling of Secure Boot support without reboot comes and goes, particularly in downstream kernels. Kernel modules are such an important diagnostic tool, and not everyone plans ahead and disables Secure Boot in case they need to load kernel modules later. >> And for the record, my computer's UEFI firmware is so old that >> "Secure Boot" cannot even be enabled at all, even if I wanted to. > > Meh. That means your computer was made before Microsoft started having > vendors require UEFI firmware to include their keys for Windows > certification (which was in 2006/2007). I'm surprised it still works. > More power to you, I guess? Last time I checked this, the Microsoft keys required for Windows certification were not those used to sign third-party binaries like the Fedora shim (the “Microsoft Corporation Third Party Marketplace Root”). You could see the difference in Hyper-V configurations, where the default Secure Boot configuration cannot boot Fedora. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ 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
Re: New memory tester application potentially to replace memtest86+: PCMemTest
Chris Murphy wrote: > This is such an old argument. I know you've been around in Fedora long > enough to actually understand this stuff if you really wanted to at > least not spread misinformation. I do not see how I am spreading misinformation. I think you are misunderstanding me. I do not intend to blame Microsoft for all the issues with the Secure Boot spec, they are only the monopoly for the signature of the initial bootloader. See my reply to Neal Gompa. > Microsoft does not approve or disapprove of operating systems. They > have an EFI signing program for developers. They are signing just our > shim bootloader. Fedora signs the other things in the boot chain. Where have I claimed anything else? The fact is still that the requirement for Microsoft to sign the initial bootloader gives them veto power over any operating system running on users' computers. And that is the one and only flaw (out of several) in the spec in which Microsoft is involved. The remaining issues are inherent to the spec itself. > Anyone can enroll their own signing keys with the firmware, sign the > bootloader, kernel and kernel modules, including 3rd party. You can > even mix and match signed binaries. And those binaries will comply > with a Secure Boot enabled system just fine, without having Microsoft > signatures on anything. Yes that's tedious and it would be better if > it were easier than it is right now. While I appreciate that the shim developers introduced this workaround (IIRC, it actually comes from openSUSE developers, not Fedora or Red Hat developers), this is absolutely impractical compared to just disabling the restrictions altogether. > Windows supports hibernation, with UEFI Secure Boot enabled. We don't > because Linux hibernation images are inherently insecure by design and > thus are a loophole for thwarting the Secure Boot regime. I do not want my computer to impose a regime on me. I want to decide what I run on my own computer, I do not want my computer to decide for me. Say no to Treacherous Computing! > Therefore a kernel lockdown policy is applied to disallow hibernation if > Secure Boot is enabled. It can be fixed, but the resources to finish that > work have not yet materialized. Even that will still not fix the other restrictions inherently caused by this security regime. > Literally none of this is Microsoft's fault. I have never claimed otherwise. > And rootkits predate UEFI. Yet, we were running just fine all these times without something like "Secure Boot". 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
Re: New memory tester application potentially to replace memtest86+: PCMemTest
Neal Gompa wrote: > Don't blame Microsoft for our failings. The fact that we can't do > hibernation or offer an easy path for third-party kernel modules to > function in a Secure Boot environment is *entirely* our fault. After > shim->grub2, Microsoft's trust ends and ours begins. We use *our* > certificate from GRUB onward. Sorry, there is a misunderstanding there. I did not intend to blame Microsoft for the restrictions within the kernel Linux imposed by the security model. There are 2 separate issues here: 1. Any operating system (in practice, the initial bootloader, shim in our case, but that is shipped by the operating system) must be signed by Microsoft to boot at all. AND 2. The security model prevents basic Linux kernel functionality. Both are ultimately failures of the UEFI spec and not of Microsoft. Microsoft is not a party to issue 2 at all. > The fact that hibernation is broken in Secure Boot is entirely the > fault of the engineers that were in charge of developing the Fedora > kernel and bootloader security mechanism, because they created the > patch set that made it functionally impossible to make it work. That > is, it's the LOCKDOWN feature layered on Secure Boot, not Secure Boot > itself. The thing is, the engineers claim that this LOCKDOWN "feature" is necessary to comply with the Secure Boot spec. I know some other distributions have a different interpretation, which makes this security entirely moot, because if the non-locked-down kernels break the security model, it is enough to have one distribution offering a signature path to such a kernel and the security model is already broken. But despite that, Red Hat does not want to take the risk of being held responsible for breaking the security model. > It's obvious Secure Boot itself is no impediment to hibernation, since > both Windows and macOS (both users of Secure Boot) can do hibernation just > fine. I don't know what they do differently. All I know is that it is not allowed by the Fedora kernel under Secure Boot restrictions. There are also other, more subtle restrictions, such as banning even root from accessing kernel memory. > Meh. That means your computer was made before Microsoft started having > vendors require UEFI firmware to include their keys for Windows > certification (which was in 2006/2007). I'm surprised it still works. > More power to you, I guess? It is actually an ASUS P8Z68-V motherboard, introduced in 2011. It is labeled as "Windows 7 ready". According to: https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Secure_boot_criticism the Secure Boot requirement was introduced with the Windows 8 certification in 2011, which my motherboard predates. 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
Re: New memory tester application potentially to replace memtest86+: PCMemTest
On 2/9/21 10:53 AM, Vít Ondruch wrote: Dne 08. 02. 21 v 21:44 Chris Murphy napsal(a): On Mon, Feb 8, 2021 at 2:46 AM Vít Ondruch wrote: Being devils advocate, but should we have the memtest86 or similar by default? I have certainly not used this feature in my 10+ yeas with Fedora. You mean get rid of it (from media and installations)? Yes, that is my proposal. Because we install it unconditionally already, even though it's a BIOS only utility and there isn't a boot entry for it in the bootloader. It's a bit obscure how to use it, given there's no menu entry for it. Ah, good to know that I have it on my system. I'm going to remove it right now. Enjoy the 357 KB space savings. :) I don't think this is utility, which is targets typical Fedora user. Here is PR proposing the removal: https://pagure.io/fedora-kickstarts/pull-request/754 A memory testing utility is certainly something useful in ruling out hardware reasons for system crashes. Even Microsoft has included one in recent versions of Windows. Being BIOS only is a problem, yes, but that makes it even more useful to have on the installation media, because I can enable the legacy BIOS CSM and boot the installation DVD on my UEFI systems, while I can't really install it on my hard drive and enable it in the GRUB menu if I have an UEFI install. Now, I would need to use a different installation media to run this tool for the sake of reducing the >2GB installation image by several kilobytes. Doesn't sound like a great idea to me. I agree it should not be installed by default on UEFI systems and I think it should probably have been enabled by default in the GRUB menu on BIOS systems. I also agree an alternative like PCMemTest is needed for UEFI systems, because not all systems have legacy BIOS CSMs. 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
Re: New memory tester application potentially to replace memtest86+: PCMemTest
Dne 09. 02. 21 v 10:08 Roberto Ragusa napsal(a): On 2/8/21 10:46 AM, Vít Ondruch wrote: Being devils advocate, but should we have the memtest86 or similar by default? I have certainly not used this feature in my 10+ yeas with Fedora. I've not used GNOME in my 18 years with Fedora (plus 5 pre-Fedora). Can we consider removing it? Have you installed Gnome by default? You probably went with KDE spin or some other spins so Gnome was never part of your system. Better example would be if you argued that KDE should be installed for every Gnome user even though they don't use it. Vít (Apologies if you are using some other desktop or if you are not using desktop at all. I just picked up KDE as the second most popular desktop choice). Having memtest86 saved my life just a few months ago: random crashes, apparently caused by pressing in the middle of the keyboard. It was able to demonstrate _live_ that the pressure was causing bit flips. Press, errors, don't press, no more errors (including appearance/disappearance of vertical bands in the display, because of integrated chipset, VRAM=RAM). Opened the laptop, reseated two DIMMs, TESTED AGAIN, TESTED AGAIN, shaken the laptop, TESTED AGAIN, no problem anymore since then. Regards. 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
Re: New memory tester application potentially to replace memtest86+: PCMemTest
On 2/8/21 10:46 AM, Vít Ondruch wrote: Being devils advocate, but should we have the memtest86 or similar by default? I have certainly not used this feature in my 10+ yeas with Fedora. I've not used GNOME in my 18 years with Fedora (plus 5 pre-Fedora). Can we consider removing it? Having memtest86 saved my life just a few months ago: random crashes, apparently caused by pressing in the middle of the keyboard. It was able to demonstrate _live_ that the pressure was causing bit flips. Press, errors, don't press, no more errors (including appearance/disappearance of vertical bands in the display, because of integrated chipset, VRAM=RAM). Opened the laptop, reseated two DIMMs, TESTED AGAIN, TESTED AGAIN, shaken the laptop, TESTED AGAIN, no problem anymore since then. Regards. -- Roberto Ragusamail at robertoragusa.it ___ 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
Re: New memory tester application potentially to replace memtest86+: PCMemTest
Dne 08. 02. 21 v 21:44 Chris Murphy napsal(a): On Mon, Feb 8, 2021 at 2:46 AM Vít Ondruch wrote: Being devils advocate, but should we have the memtest86 or similar by default? I have certainly not used this feature in my 10+ yeas with Fedora. You mean get rid of it (from media and installations)? Yes, that is my proposal. Because we install it unconditionally already, even though it's a BIOS only utility and there isn't a boot entry for it in the bootloader. It's a bit obscure how to use it, given there's no menu entry for it. Ah, good to know that I have it on my system. I'm going to remove it right now. I don't think this is utility, which is targets typical Fedora user. Here is PR proposing the removal: https://pagure.io/fedora-kickstarts/pull-request/754 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
Re: New memory tester application potentially to replace memtest86+: PCMemTest
On Mon, Feb 8, 2021 at 7:13 PM Kevin Kofler via devel wrote: > > Chris Murphy wrote: > > If you want to take the risk of acquiring a rootkit that can > > permanently take control of your firmware, that is up to you. It > > should not be a distribution recommendation to subject users to such > > bad advice. > > And the "good advice" would be to accept that your computer will only run > operating systems approved by Microsoft and to accept a security model that > prevents basic functionality such as hibernation, third-party kernel > modules, etc.? This is such an old argument. I know you've been around in Fedora long enough to actually understand this stuff if you really wanted to at least not spread misinformation. Microsoft does not approve or disapprove of operating systems. They have an EFI signing program for developers. They are signing just our shim bootloader. Fedora signs the other things in the boot chain. Anyone can enroll their own signing keys with the firmware, sign the bootloader, kernel and kernel modules, including 3rd party. You can even mix and match signed binaries. And those binaries will comply with a Secure Boot enabled system just fine, without having Microsoft signatures on anything. Yes that's tedious and it would be better if it were easier than it is right now. Windows supports hibernation, with UEFI Secure Boot enabled. We don't because Linux hibernation images are inherently insecure by design and thus are a loophole for thwarting the Secure Boot regime. Therefore a kernel lockdown policy is applied to disallow hibernation if Secure Boot is enabled. It can be fixed, but the resources to finish that work have not yet materialized. Literally none of this is Microsoft's fault. And rootkits predate UEFI. -- 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
Re: New memory tester application potentially to replace memtest86+: PCMemTest
On Mon, Feb 8, 2021 at 9:13 PM Kevin Kofler via devel wrote: > > Chris Murphy wrote: > > If you want to take the risk of acquiring a rootkit that can > > permanently take control of your firmware, that is up to you. It > > should not be a distribution recommendation to subject users to such > > bad advice. > > And the "good advice" would be to accept that your computer will only run > operating systems approved by Microsoft and to accept a security model that > prevents basic functionality such as hibernation, third-party kernel > modules, etc.? > Don't blame Microsoft for our failings. The fact that we can't do hibernation or offer an easy path for third-party kernel modules to function in a Secure Boot environment is *entirely* our fault. After shim->grub2, Microsoft's trust ends and ours begins. We use *our* certificate from GRUB onward. The fact that hibernation is broken in Secure Boot is entirely the fault of the engineers that were in charge of developing the Fedora kernel and bootloader security mechanism, because they created the patch set that made it functionally impossible to make it work. That is, it's the LOCKDOWN feature layered on Secure Boot, not Secure Boot itself. It's obvious Secure Boot itself is no impediment to hibernation, since both Windows and macOS (both users of Secure Boot) can do hibernation just fine. The fact that third-party kernel modules are nearly impossible to set up in Secure Boot is entirely the fault of engineers who designed the certificate trust mechanism to not offer a path for semi-interactive or non-interactive trust scenarios like we have for package and repository signatures. It is theoretically possible for third-party stuff to work in a Secure Boot environment, but the path to get there is so onerous because nobody who makes this stuff for Linux cares to make this easy to work with. The trust mechanisms for Secure Boot are not fundamentally any different from how trust works for GPG (they're both rooted in PKI architectures). The difference is that expanding trust at the Linux kernel level is deliberately under-documented and considered unsupported. Additionally, creating signed kernel module packages has been broken since the beginning, since nobody cared to actually *fix* the kernel module packaging system to account for it. I've been trying to untangle this mess for months because I'm frustrated by how stupid the situation is and how we've never *tried* to make having a secure system easier. None of this had to be this way. It is so by our own inaction, not by the action of Microsoft. > And for the record, my computer's UEFI firmware is so old that "Secure Boot" > cannot even be enabled at all, even if I wanted to. > Meh. That means your computer was made before Microsoft started having vendors require UEFI firmware to include their keys for Windows certification (which was in 2006/2007). I'm surprised it still works. More power to you, I guess? -- 真実はいつも一つ！/ 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
Re: New memory tester application potentially to replace memtest86+: PCMemTest
Chris Murphy wrote: > If you want to take the risk of acquiring a rootkit that can > permanently take control of your firmware, that is up to you. It > should not be a distribution recommendation to subject users to such > bad advice. And the "good advice" would be to accept that your computer will only run operating systems approved by Microsoft and to accept a security model that prevents basic functionality such as hibernation, third-party kernel modules, etc.? And for the record, my computer's UEFI firmware is so old that "Secure Boot" cannot even be enabled at all, even if I wanted to. 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
Re: New memory tester application potentially to replace memtest86+: PCMemTest
On Mon, Feb 8, 2021 at 5:19 PM Kevin Kofler via devel wrote: > > Chris Murphy wrote: > > Yeah I definitely do not want Fedora in a position where anyone has to > > give users advice like "you need to disable UEFI Secure Boot" in order > > to do X. Be it testing RAM or anything else. > > Why would anyone want to NOT disable Restricted Boot? (Assuming the firmware > is not broken and lets them disable it, as it is supposed to.) If you want to take the risk of acquiring a rootkit that can permanently take control of your firmware, that is up to you. It should not be a distribution recommendation to subject users to such bad advice. -- 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
Re: New memory tester application potentially to replace memtest86+: PCMemTest
Chris Murphy wrote: > Yeah I definitely do not want Fedora in a position where anyone has to > give users advice like "you need to disable UEFI Secure Boot" in order > to do X. Be it testing RAM or anything else. Why would anyone want to NOT disable Restricted Boot? (Assuming the firmware is not broken and lets them disable it, as it is supposed to.) 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
Re: New memory tester application potentially to replace memtest86+: PCMemTest
On Mon, Feb 8, 2021 at 4:47 PM Martin Whitaker wrote: > > On 07/02/2021 22:23, Chris Murphy wrote: > > On Sun, Feb 7, 2021 at 2:08 AM Neal Gompa wrote: > >> > >> Hey all, > >> > >> I discovered today that there's a new replacement for memtest86+ that > >> appears to even have UEFI support called PCMemTest[0]. > >> > >> The main reason I call out to this is because we don't have a memory > >> tester offering in our UEFI boot variant for the Fedora live media, > >> and this is actively maintained (unlike memtest86+, which we currently > >> use...). > >> > >> Mageia is shipping this starting with Mageia 8[1], and we should > >> consider shipping this with Fedora 34. > > > > > > * A listed limitation: "When booted on a UEFI system, keyboard input > > will only be seen if the CSM is enabled in the BIOS. Without this, the > > test will run, but you will be unable to alter the configuration." > > > > - How does a CSM provide keyboard input to an EFI application? Or does > > this mean with CSM enabled, we'd use the BIOS version of the memory > > tester; and with CSM disabled, we'd use the UEFI version of the memory > > tester? > > On all the machines in my possession, enabling the CSM enables emulation > of the keyboard controller ports (ports 0x60 and 0x64), even when booted > in UEFI mode. That may not be true for all BIOSs of course. OK. I'm confused (not unusual) and also ignorant of how the keyboard driver situation works on UEFI without the CSM enabled. Because without it enabled, I definitely have working keyboard on all my systems in EFI shell. That suggests the keyboard driver is available, isn't due to GRUB providing one. I see GRUB has usb_keyboard.mod but I don't see it as one of the modules we're baking into Fedora's grubx64.efi. https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/grub.macros I guess I'm trying to figure out the scope of the "does not have working keyboard with native UEFI plus Secure Boot" problem. > > - As far as I'm aware, enabling CSM requires disabling UEFI Secure Boot. > > Probably so. At which point you are limited to running the memory tests > with the default configuration (which is to run all tests using a single > processor). > > As I don't use secure boot, I wasn't really motivated to start writing a > replacement keyboard driver. Yeah I definitely do not want Fedora in a position where anyone has to give users advice like "you need to disable UEFI Secure Boot" in order to do X. Be it testing RAM or anything else. -- 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
Re: New memory tester application potentially to replace memtest86+: PCMemTest
On 2/8/21 2:44 PM, Chris Murphy wrote: On Mon, Feb 8, 2021 at 2:46 AM Vít Ondruch wrote: Being devils advocate, but should we have the memtest86 or similar by default? I have certainly not used this feature in my 10+ yeas with Fedora. You mean get rid of it (from media and installations)? Because we install it unconditionally already, even though it's a BIOS only utility and there isn't a boot entry for it in the bootloader. It's a bit obscure how to use it, given there's no menu entry for it. There's also the fact it doesn't seem to work real well with modern hardware[0][1]. [0] - https://bugzilla.redhat.com/show_bug.cgi?id=1815742 [1] - https://bugzilla.redhat.com/show_bug.cgi?id=1869211 ___ 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
Re: New memory tester application potentially to replace memtest86+: PCMemTest
On Mon, Feb 8, 2021 at 2:46 AM Vít Ondruch wrote: > > Being devils advocate, but should we have the memtest86 or similar by > default? I have certainly not used this feature in my 10+ yeas with Fedora. > You mean get rid of it (from media and installations)? Because we install it unconditionally already, even though it's a BIOS only utility and there isn't a boot entry for it in the bootloader. It's a bit obscure how to use it, given there's no menu entry for it. -- 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
Re: New memory tester application potentially to replace memtest86+: PCMemTest
Being devils advocate, but should we have the memtest86 or similar by default? I have certainly not used this feature in my 10+ yeas with Fedora. Vít Dne 07. 02. 21 v 10:07 Neal Gompa napsal(a): Hey all, I discovered today that there's a new replacement for memtest86+ that appears to even have UEFI support called PCMemTest[0]. The main reason I call out to this is because we don't have a memory tester offering in our UEFI boot variant for the Fedora live media, and this is actively maintained (unlike memtest86+, which we currently use...). Mageia is shipping this starting with Mageia 8[1], and we should consider shipping this with Fedora 34. [0]: https://github.com/martinwhitaker/pcmemtest [1]: https://wiki.mageia.org/en/Mageia_8_Release_Notes#PCMemTest -- 真実はいつも一つ！/ 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 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
Re: New memory tester application potentially to replace memtest86+: PCMemTest
On Sun, Feb 7, 2021 at 2:08 AM Neal Gompa wrote: > > Hey all, > > I discovered today that there's a new replacement for memtest86+ that > appears to even have UEFI support called PCMemTest[0]. > > The main reason I call out to this is because we don't have a memory > tester offering in our UEFI boot variant for the Fedora live media, > and this is actively maintained (unlike memtest86+, which we currently > use...). > > Mageia is shipping this starting with Mageia 8[1], and we should > consider shipping this with Fedora 34. * A listed limitation: "When booted on a UEFI system, keyboard input will only be seen if the CSM is enabled in the BIOS. Without this, the test will run, but you will be unable to alter the configuration." - How does a CSM provide keyboard input to an EFI application? Or does this mean with CSM enabled, we'd use the BIOS version of the memory tester; and with CSM disabled, we'd use the UEFI version of the memory tester? - As far as I'm aware, enabling CSM requires disabling UEFI Secure Boot. * Any UEFI memory tester needs to be signed with Fedora's signing key, same as grubx64.efi so that it works with UEFI Secure boot enabled. -- 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
Re: New memory tester application potentially to replace memtest86+: PCMemTest
On Sun, Feb 07, 2021 at 11:03:38AM -0500, Stephen John Smoogen wrote: > On Sun, 7 Feb 2021 at 09:41, Roberto Ragusa wrote: > > > On 2/7/21 12:16 PM, drago01 wrote: > > > It can only be an alternative, not a replacement, since it is > > dropping features: > > > > > > «In particular, no attempt is made to measure the cache and main > > memory speed, > > > or to identify and report the DRAM type.» > > > > > > > > > Which is nice to have but not really the point of a memory tester ... > > > > I'm pointing out that memtest86+ is not just a memory tester. > > Is there any other tool covering that functionality? Memory type and speed information is available through dmi. In systemd we recently merged a patch [1] to make this information available to unprivileged users, so that gnome can display it in a pretty way: $ udevadm info /sys/class/dmi/id/ P: /devices/virtual/dmi/id ... E: MODALIAS=dmi:bvnLENOVO:bvrN1FET68W(1.42):bd03/13/2019... ... E: MEMORY_ARRAY_LOCATION=System Board Or Motherboard E: MEMORY_ARRAY_NUM_DEVICES=2 ... E: MEMORY_DEVICE_0_SIZE=4294967296 E: MEMORY_DEVICE_0_FORM_FACTOR=Chip E: MEMORY_DEVICE_0_TYPE=LPDDR3 E: MEMORY_DEVICE_0_SPEED_MTS=1867 E: MEMORY_DEVICE_0_MANUFACTURER=Samsung E: MEMORY_DEVICE_0_PART_NUMBER=K4E6E304EE-EGCF ... E: MEMORY_DEVICE_1_SIZE=4294967296 E: MEMORY_DEVICE_1_FORM_FACTOR=SODIMM E: MEMORY_DEVICE_1_LOCATOR=ChannelB E: MEMORY_DEVICE_1_BANK_LOCATOR=BANK 2 E: MEMORY_DEVICE_1_TYPE=LPDDR3 ... [1] https://github.com/systemd/systemd/pull/17837 This is just repeated from what the firmware gives us, not measured, but might be good enough. 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
Re: New memory tester application potentially to replace memtest86+: PCMemTest
«In particular, no attempt is made to measure the cache and main memory speed, or to identify and report the DRAM type.» Which is nice to have but not really the point of a memory tester ... When the tester reports errors then it is handy to know as much as possible about where the errors lie, including the manufacturer and part number if an error can be isolated to an address range. For a system which added memory in mid-life using a different brand of RAM, it is helpful to confirm the brand which is failing. /usr/sbin/dmidecode reports what it knows, but that requires cross-referencing etc. ___ 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
Re: New memory tester application potentially to replace memtest86+: PCMemTest
On Sun, 7 Feb 2021 at 09:41, Roberto Ragusa wrote: > On 2/7/21 12:16 PM, drago01 wrote: > > > > On Sunday, February 7, 2021, Roberto Ragusa <mailto:m...@robertoragusa.it>> wrote: > > > > It can only be an alternative, not a replacement, since it is > dropping features: > > > > «In particular, no attempt is made to measure the cache and main > memory speed, > > or to identify and report the DRAM type.» > > > > > > Which is nice to have but not really the point of a memory tester ... > > I'm pointing out that memtest86+ is not just a memory tester. > Is there any other tool covering that functionality? > > Probably not because for more and more modern hardware it gets harder and harder to get that information. Heck even 'testing' memory is hard enough these days because a lot of hardware is built around covering up any problem with the hardware because it is expected to fail and the hardware itself will see that, mark it bad and set something else up as good. -- Stephen J Smoogen. ___ 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
Re: New memory tester application potentially to replace memtest86+: PCMemTest
On 2/7/21 12:16 PM, drago01 wrote: On Sunday, February 7, 2021, Roberto Ragusa mailto:m...@robertoragusa.it>> wrote: It can only be an alternative, not a replacement, since it is dropping features: «In particular, no attempt is made to measure the cache and main memory speed, or to identify and report the DRAM type.» Which is nice to have but not really the point of a memory tester ... I'm pointing out that memtest86+ is not just a memory tester. Is there any other tool covering that functionality? -- Roberto Ragusamail at robertoragusa.it ___ 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
Re: New memory tester application potentially to replace memtest86+: PCMemTest
On Sunday, February 7, 2021, Roberto Ragusa wrote: > On 2/7/21 10:07 AM, Neal Gompa wrote: > >> Hey all, >> >> I discovered today that there's a new replacement for memtest86+ that >> appears to even have UEFI support called PCMemTest[0]. >> > > It can only be an alternative, not a replacement, since it is dropping > features: > > «In particular, no attempt is made to measure the cache and main memory > speed, > or to identify and report the DRAM type.» Which is nice to have but not really the point of a memory tester ... > Regards. > -- >Roberto Ragusamail at robertoragusa.it > ___ > 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.or > g/archives/list/devel@lists.fedoraproject.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
Re: New memory tester application potentially to replace memtest86+: PCMemTest
On 2/7/21 10:07 AM, Neal Gompa wrote: Hey all, I discovered today that there's a new replacement for memtest86+ that appears to even have UEFI support called PCMemTest[0]. It can only be an alternative, not a replacement, since it is dropping features: «In particular, no attempt is made to measure the cache and main memory speed, or to identify and report the DRAM type.» Regards. -- Roberto Ragusamail at robertoragusa.it ___ 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
New memory tester application potentially to replace memtest86+: PCMemTest
Hey all, I discovered today that there's a new replacement for memtest86+ that appears to even have UEFI support called PCMemTest[0]. The main reason I call out to this is because we don't have a memory tester offering in our UEFI boot variant for the Fedora live media, and this is actively maintained (unlike memtest86+, which we currently use...). Mageia is shipping this starting with Mageia 8[1], and we should consider shipping this with Fedora 34. [0]: https://github.com/martinwhitaker/pcmemtest [1]: https://wiki.mageia.org/en/Mageia_8_Release_Notes#PCMemTest -- 真実はいつも一つ！/ 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
Re: Unable to push into memtest86+/master
- Original Message - > > > - Original Message - > > On Fri, 8 Jan 2016 11:12:37 -0500 (EST) > > Jaroslav Skarvada <jskar...@redhat.com> wrote: > > > > > $ git push -v > > > Pushing to ssh://jskar...@pkgs.fedoraproject.org/memtest86+ > > > WARNING: 'memtest86+' is an alias for 'rpms/memtest86+' > > > FATAL: W any memtest86+ jskarvad DENIED by fallthru > > > (or you mis-spelled the reponame) > > > fatal: Could not read from remote repository. > > > > > > Please make sure you have the correct access rights > > > and the repository exists. > > > > > > Apparently I have the correct rights: > > > https://admin.fedoraproject.org/pkgdb/package/rpms/memtest86+/ > > > > > > Any idea what's wrong? > > > > Odd. The rights look correct also in gitolite. ;( > > > > At least right now. Can you try pushing again and confirm it's still > > broken? > > > > kevin > > > Hi Kevin, it's still broken for me. I tried to do fresh checkout (this time > with pure git, no fedpkg front-end): > > $ git clone 'ssh://jskar...@pkgs.fedoraproject.org/memtest86+' > Cloning into 'memtest86+'... > WARNING: 'memtest86+' is an alias for 'rpms/memtest86+' > remote: Counting objects: 573, done. > remote: Compressing objects: 100% (342/342), done. > remote: Total 573 (delta 275), reused 458 (delta 207) > Receiving objects: 100% (573/573), 241.70 KiB | 0 bytes/s, done. > Resolving deltas: 100% (275/275), done. > Checking connectivity... done. > > Then I updated SPEC file and tried to push the changes: > > $ git push > WARNING: 'memtest86+' is an alias for 'rpms/memtest86+' > FATAL: W any memtest86+ jskarvad DENIED by fallthru > (or you mis-spelled the reponame) > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. > > I tried to push into 'grep/master' and it worked. So It seems that only > the memtest86+ is broken for me. It is really weird as I am proven packager > so it shouldn't complain about ACLs > > thanks & regards > > Jaroslav > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > Created ticket: https://fedorahosted.org/fedora-infrastructure/ticket/5058 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unable to push into memtest86+/master
- Original Message - > On Fri, 8 Jan 2016 11:12:37 -0500 (EST) > Jaroslav Skarvada <jskar...@redhat.com> wrote: > > > $ git push -v > > Pushing to ssh://jskar...@pkgs.fedoraproject.org/memtest86+ > > WARNING: 'memtest86+' is an alias for 'rpms/memtest86+' > > FATAL: W any memtest86+ jskarvad DENIED by fallthru > > (or you mis-spelled the reponame) > > fatal: Could not read from remote repository. > > > > Please make sure you have the correct access rights > > and the repository exists. > > > > Apparently I have the correct rights: > > https://admin.fedoraproject.org/pkgdb/package/rpms/memtest86+/ > > > > Any idea what's wrong? > > Odd. The rights look correct also in gitolite. ;( > > At least right now. Can you try pushing again and confirm it's still > broken? > > kevin > Hi Kevin, it's still broken for me. I tried to do fresh checkout (this time with pure git, no fedpkg front-end): $ git clone 'ssh://jskar...@pkgs.fedoraproject.org/memtest86+' Cloning into 'memtest86+'... WARNING: 'memtest86+' is an alias for 'rpms/memtest86+' remote: Counting objects: 573, done. remote: Compressing objects: 100% (342/342), done. remote: Total 573 (delta 275), reused 458 (delta 207) Receiving objects: 100% (573/573), 241.70 KiB | 0 bytes/s, done. Resolving deltas: 100% (275/275), done. Checking connectivity... done. Then I updated SPEC file and tried to push the changes: $ git push WARNING: 'memtest86+' is an alias for 'rpms/memtest86+' FATAL: W any memtest86+ jskarvad DENIED by fallthru (or you mis-spelled the reponame) fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. I tried to push into 'grep/master' and it worked. So It seems that only the memtest86+ is broken for me. It is really weird as I am proven packager so it shouldn't complain about ACLs thanks & regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unable to push into memtest86+/master
On 01/08/2016 08:22 AM, Jerry James wrote: On Fri, Jan 8, 2016 at 9:12 AM, Jaroslav Skarvada <jskar...@redhat.com> wrote: $ git push -v Pushing to ssh://jskar...@pkgs.fedoraproject.org/memtest86+ WARNING: 'memtest86+' is an alias for 'rpms/memtest86+' And what's up with this warning? I was just puzzling over that myself. I haven't seen it before this morning. What does it mean? They added namespacing to the git repo. I expect the tools will be updated soon. https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/message/ZMGE4QS6UHU5WSENM5QDROB26TXEOXOS/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unable to push into memtest86+/master
On Fri, 8 Jan 2016 11:12:37 -0500 (EST) Jaroslav Skarvada <jskar...@redhat.com> wrote: > $ git push -v > Pushing to ssh://jskar...@pkgs.fedoraproject.org/memtest86+ > WARNING: 'memtest86+' is an alias for 'rpms/memtest86+' > FATAL: W any memtest86+ jskarvad DENIED by fallthru > (or you mis-spelled the reponame) > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. > > Apparently I have the correct rights: > https://admin.fedoraproject.org/pkgdb/package/rpms/memtest86+/ > > Any idea what's wrong? Odd. The rights look correct also in gitolite. ;( At least right now. Can you try pushing again and confirm it's still broken? kevin pgpD5c6wehyOU.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unable to push into memtest86+/master
On Fri, Jan 8, 2016 at 9:12 AM, Jaroslav Skarvada <jskar...@redhat.com> wrote: > $ git push -v > Pushing to ssh://jskar...@pkgs.fedoraproject.org/memtest86+ > WARNING: 'memtest86+' is an alias for 'rpms/memtest86+' And what's up with this warning? I was just puzzling over that myself. I haven't seen it before this morning. What does it mean? -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Unable to push into memtest86+/master
$ git push -v Pushing to ssh://jskar...@pkgs.fedoraproject.org/memtest86+ WARNING: 'memtest86+' is an alias for 'rpms/memtest86+' FATAL: W any memtest86+ jskarvad DENIED by fallthru (or you mis-spelled the reponame) fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Apparently I have the correct rights: https://admin.fedoraproject.org/pkgdb/package/rpms/memtest86+/ Any idea what's wrong? thanks & regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: memtest86+
- Original Message - On 06/01/2011 09:59 PM, Genes MailLists wrote: Best I can tell the current version of memtest86+ in Fedora is v4.10 which is too old for Sandy Bridge which needs version v4.20. Anyone know if there is some reason we haven't updated to the current version (released January 2011) ? This also means anyone using the memtest86+ from install (F15 or F14) will not be able to run it if they have Sandy Bridge - it just hangs. Probably worth noting that in the wiki somewhere too .. -- 4.20 is in rawhide since March 07. I will push it to f14/f15 also. Please file a bug next time thanks regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: memtest86+
On 06/02/2011 04:44 AM, Jaroslav Skarvada wrote: - Original Message - 4.20 is in rawhide since March 07. I will push it to f14/f15 also. Please file a bug next time thanks regards Jaroslav Thanks - I did file a bug and see that you replied to the bug too - so thanks. (my bugzilla account name is a bit diffderent :-)) gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
memtest86+
Best I can tell the current version of memtest86+ in Fedora is v4.10 which is too old for Sandy Bridge which needs version v4.20. Anyone know if there is some reason we haven't updated to the current version (released January 2011) ? Thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: memtest86+
On Wed, Jun 1, 2011 at 10:59 PM, Genes MailLists li...@sapience.com wrote: Best I can tell the current version of memtest86+ in Fedora is v4.10 which is too old for Sandy Bridge which needs version v4.20. Anyone know if there is some reason we haven't updated to the current version (released January 2011) ? Thanks. report a bug or send a e-mail to the package owner to update it. Itamar Reis Peixoto msn, google talk: ita...@ispbrasil.com.br +55 11 4063 5033 (FIXO SP) +55 34 9158 9329 (TIM) +55 34 8806 3989 (OI) +55 34 3221 8599 (FIXO MG) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: memtest86+
On 06/01/2011 09:59 PM, Genes MailLists wrote: Best I can tell the current version of memtest86+ in Fedora is v4.10 which is too old for Sandy Bridge which needs version v4.20. Anyone know if there is some reason we haven't updated to the current version (released January 2011) ? This also means anyone using the memtest86+ from install (F15 or F14) will not be able to run it if they have Sandy Bridge - it just hangs. Probably worth noting that in the wiki somewhere too .. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
