[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
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.
Hi Vitaly,
On Sat, Jul 31, 2021 at 10:28 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org 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?
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.
On Sat, Jul 31, 2021 at 1:28 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org 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.
El sáb, 31 jul 2021 a las 2:58, Chris Murphy (lists@colorremedies.com) 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.gi...
Best regards.
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.
On Sun, Aug 1, 2021 at 6:49 PM Gordon Messmer gordon.messmer@gmail.com 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.
On Sun, Aug 1, 2021 at 4:55 PM Neal Gompa ngompa13@gmail.com wrote:
On Sun, Aug 1, 2021 at 6:49 PM Gordon Messmer gordon.messmer@gmail.com 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.
On 8/1/21 8:46 PM, Chris Murphy wrote:
On Sun, Aug 1, 2021 at 4:55 PM Neal Gompa ngompa13@gmail.com wrote:
On Sun, Aug 1, 2021 at 6:49 PM Gordon Messmer gordon.messmer@gmail.com 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
On Sun, Aug 1, 2021 at 7:51 PM Steven A. Falco stevenfalco@gmail.com 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...
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.
On Mon, Aug 2, 2021 at 12:15 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org 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.
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.
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
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.
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
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-x6... https://gordonmessmer.fedorapeople.org/pcmemtest-unsigned-x64/
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-x6... 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
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 /<path>/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.
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 /<path>/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
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.
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
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 <path>/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 <path>/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.
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 <path>/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/msg00001.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=00000000 ECX=c0000080 EDX=00000000 ESI=00088ffe EDI=00000000 EBP=00000000 ESP=00137100 EIP=0010027a EFL=00200086 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0018 00000000 ffffffff 00c09300 DPL=0 DS [-WA] CS =0010 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA] SS =0018 00000000 ffffffff 00c09300 DPL=0 DS [-WA] DS =0018 00000000 ffffffff 00c09300 DPL=0 DS [-WA] FS =0018 00000000 ffffffff 00c09300 DPL=0 DS [-WA] GS =0018 00000000 ffffffff 00c09300 DPL=0 DS [-WA] LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS64-busy GDT= 00000000000010d0 00000020 IDT= 000000003f573018 00000fff CR0=80010033 CR2=0000000000000000 CR3=0000000000010000 CR4=00000668 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000d00 Code=?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? <??> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
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?
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.
From what I see, no replacement was ever added to the boot options, so none exists now (although it is performed by the kernel at boot). Considering that https://unix.stackexchange.com/revisions/439769/5#:~:text=Yes%2C%20there%20i... appears to indicate that this situation has reversed, does any desire exist to re-add the entrant to the boot options?
On Wed, Aug 27, 2025 at 6:19 PM Roke Beedell via devel < devel@lists.fedoraproject.org> wrote:
From what I see, no replacement was ever added to the boot options, so none exists now (although it is performed by the kernel at boot). Considering that https://unix.stackexchange.com/revisions/439769/5#:~:text=Yes%2C%20there%20i... appears to indicate that this situation has reversed, does any desire exist to re-add the entrant to the boot options?
It would be great if somebody could add it back. If I use the upstream memtest.org image, I need to disable SecureBoot, which is inconvenient. If there's anyone interested in pushing this forward, that would be great.
Hello,
memtest86+ is already at the latest version. We automatically monitor upstream and have been responsive for updates. If you have any issues with the package please file a bug. :)
We are unable to sign these builds due to the requirements for the secure boot signing process. If there is ever a Fedora key that can sign builds and users can trust that key, we might be able to in the future. This is out of scope for the memtest86+ package.
The "memtest=N" boot argument should be working. This was enabled per https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2385. This is not as thorough of testing compared to memtest86+, but it's great for a quick sanity check.
Cheers,
On Mon, Sep 1, 2025 at 10:32 AM Jonathan Steffan jonathansteffan@gmail.com wrote:
Hello,
memtest86+ is already at the latest version. We automatically monitor upstream and have been responsive for updates. If you have any issues with the package please file a bug. :)
We are unable to sign these builds due to the requirements for the secure boot signing process. If there is ever a Fedora key that can sign builds and users can trust that key, we might be able to in the future. This is out of scope for the memtest86+ package.
The "memtest=N" boot argument should be working. This was enabled per https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2385. This is not as thorough of testing compared to memtest86+, but it's great for a quick sanity check.
It is possible to request Fedora to sign it. You will probably need to make some packaging changes to support it, but it can be done.
You can file a ticket with releng to get it done.
-- 真実はいつも一つ!/ Always, there's only one truth!
On Mon, Sep 1, 2025 at 8:36 AM Neal Gompa ngompa13@gmail.com wrote:
It is possible to request Fedora to sign it. You will probably need to make some packaging changes to support it, but it can be done.
Ah cool. I didn't know that we had made any progress on upgrading the signing process and adding our own keys. I've tried following the discussions.
I assume end-users will still have to enroll an additional key? Are we enrolling keys automatically, on first boot or otherwise?
Will this work with Grub or is it just for sd-boot?
Are the packaging changes needed documented anywhere?
Thanks!
On Mon, Sep 1, 2025 at 11:12 AM Jonathan Steffan jonathansteffan@gmail.com wrote:
On Mon, Sep 1, 2025 at 8:36 AM Neal Gompa ngompa13@gmail.com wrote:
It is possible to request Fedora to sign it. You will probably need to make some packaging changes to support it, but it can be done.
Ah cool. I didn't know that we had made any progress on upgrading the signing process and adding our own keys. I've tried following the discussions.
I assume end-users will still have to enroll an additional key? Are we enrolling keys automatically, on first boot or otherwise?
Will this work with Grub or is it just for sd-boot?
It would be signed with the standard Fedora key, so it should work from any boot manager that loads shim to activate the Fedora key.
Are the packaging changes needed documented anywhere?
No, though btrfs-efi is a decent example: https://src.fedoraproject.org/rpms/btrfs-efi