Bug 2137395

Scratch build failed. Details below:

BuilderException: Build failed:
Command '['rpmbuild', '-D', '_sourcedir .', '-D', '_topdir .', '-bs', '/var/tmp/thn-thlzo1rr/memtest86+.spec']' returned non-zero exit status 1.

StdOut:
error: Bad source: ./memtest86+-6.00b.tar.gz: No such file or directory


Traceback:
  File "/usr/local/lib/python3.10/site-packages/hotness/use_cases/package_scratch_build_use_case.py", line 56, in build
    result = self.builder.build(request.package, request.opts)
  File "/usr/local/lib/python3.10/site-packages/hotness/builders/koji.py", line 188, in build
    raise BuilderException(

If you think this issue is caused by some bug in the-new-hotness, please report it on the-new-hotness issue tracker: https://github.com/fedora-infra/the-new-hotness/issues

I just wanted to say I've compiled 6.00 on F36. Went straight into build64 (!) and make.

The 64-bit ELF version (ELF image is the current default for Fedora) didn't work, simply restarts the computer, clearly GRUB's "knetbsd" command doesn't know how to deal with 64-bit ELF objects.

Meanwhile, the 64-bit "bzImage" version ("memtest.bin", copied to /boot/memtest86+-6.00) works perfectly - all it needs is "linux", not "linux16" in grub.cfg (I've updated /etc/grub.d/20_memtest86+)

Since now we can have this 64-bit image, and since Fedora already doesn't support i686 for years (not to mention EL9!), I don't think there's a need for 32-bit memtest86+ and for /etc/memtest86+.conf anymore?

Releases retrieved: 6.01
Upstream release that is considered latest: 6.01
Current version/release in rawhide: 5.31-0.7.beta.fc37
URL: https://github.com/memtest86plus/memtest86plus

Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream.


Based on the information from Anitya: https://release-monitoring.org/project/1966/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/memtest86+

Scratch build failed. Details below:

BuilderException: Build failed:
Command '['rpmbuild', '-D', '_sourcedir .', '-D', '_topdir .', '-bs', '/var/tmp/thn-gy1vg4iz/memtest86+.spec']' returned non-zero exit status 1.

StdOut:
error: Bad source: ./memtest86+-6.01b.tar.gz: No such file or directory


Traceback:
  File "/usr/local/lib/python3.10/site-packages/hotness/use_cases/package_scratch_build_use_case.py", line 56, in build
    result = self.builder.build(request.package, request.opts)
  File "/usr/local/lib/python3.10/site-packages/hotness/builders/koji.py", line 188, in build
    raise BuilderException(

If you think this issue is caused by some bug in the-new-hotness, please report it on the-new-hotness issue tracker: https://github.com/fedora-infra/the-new-hotness/issues

*** Bug 2157090 has been marked as a duplicate of this bug. ***

Saw there was already a bug list on memtest 6.01 but figured I'd post what I have found to manually get it to work on Fedora 36 and Fedora 37.
Seems a different version of memtest from iso needs to be used for legacy setup versus UEFI.

Memtest not working on Fedora correctly
With Legacy BIOS boot it installs the firstmenu entry, but it fails.
Some time ago, I created the 2nd menu entry manually, and it would work with Legacy boot.
Now have discovered there is a 6.01 version, and can get it to work with manual entries, but requires different options for booting with Legacy and UEFI.

### BEGIN /etc/grub.d/20_memtest86+ ###
menuentry 'Fedora Memtest memtest86+-5.31' {
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos5'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos5 --hint-efi=hd0,msdos5 --hint-baremetal=ahci0,msdos5 --hint='hd0,msdos5'  fa908208-22bd-4031-b620-841498e0708c
	else
	  search --no-floppy --fs-uuid --set=root fa908208-22bd-4031-b620-841498e0708c
	fi
	insmod bsd
	echo	'Loading Fedora Memtest memtest86+-5.31 ...'
	knetbsd	/elf-memtest86+-5.31
}
menuentry 'Memtest' {
	echo 'Loading memdisk'
	linux16 /memdisk iso
	echo 'Loading iso'
	initrd16 /memtest86+-5.31b.iso
}
### END /etc/grub.d/20_memtest86+ ###

From https://memtest.org/ see the new 6.01 version.
Download new version.
https://memtest.org/download/v6.01/mt86plus_6.01_64.grub.iso.zip
Extract file and use isomaster mt86plus64.grub.iso 
to view content. It has two different versions of memtest 
one in legacy boot and one under efi. Extract both, and rename.

Renamed them to 
144344 memtest.leg
144384 memtest.uefi

With a legacy boot grub.cfg loads fine with.
menuentry 'Memtest' {
	linux /memtest.leg
}

With my one machine with UEFI boot the grub.cfg works with
menuentry 'Memtest' {
	linux /memtest.uefi
}
If try the leg version it gives error message of Dos Magic Number.


With the memtest installed as rpm on UEFI boot, running setup gives this.
memtest-setup 
ERROR: memtest86+ does not support EFI platforms.

Manually putting this in /boot/grub2/grub.cfg it works.

### BEGIN /etc/grub.d/20_memtest86+ ###
menuentry 'Memtest' {
	linux /memtest.uefi
}
### END /etc/grub.d/20_memtest86+ ###

Don't have enough info on how the Fedora could be updated to automatically setup the new 6.01 memtest, but does show it is possible.
Thanks.

That's why I was testing local compilation on Fedora with Fedora toolchain - everything builds and works.

I've tested both BIOS and UEFI boot from files built on F36 and F37 - yes, you need to use correct output file (memtest.bin or memtest.efi, respectively), memtest-setup already detects if system has been booted from EFI, so it's all rather trivial, just replace "knetbsd" with "linux" and get rid of the obsolete ELF stuff.

As this is an EPEL package, I've tested on AlmaLinux 9 on my Odroid H3, again no issue.

Current version simply doesn't work at all on basically any hardware. 6.0+ works flawlessly. Please update :)

Don't know enough on the /etc/grub.d setup files.
Specifically the /etc/grub.d/20_memtest86+
Has a lot of stuff in it.
Did a very simple replacement with 

# !/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry 'Memtest Legacy' {
	echo 'Loading memtest 6.01 for BIOS BOOT SYSTEM'
	linux /memtest.leg
}
menuentry 'Memtest UEFI' {
	echo 'Loading memtest 6.01 for UEFI BOOT SYSTEM'
	linux /memtest.uefi
}

On a test system, seems to create the grub.cfg file with the entries.
Only other requirement would be to copy the memtest program files from the grub.iso from site that I extracted using isomaster.
https://memtest.org/download/v6.01/mt86plus_6.01_64.grub.iso.zip
isomaster mt86plus64.grub.iso
One file is /boot/memtest and other is /EFI/BOOT/memtest
Both have same name memtest, so I renamed each one.
144344 memtest.leg
144384 memtest.uefi

Basically, would require user to select correct one. Might be way to figure which would be appropriate, but that seems to work??
Have 5 legacy machines with Fedora 36 or 37, and just one machine with Fedora 37 with UEFI. 

So, perhaps someone with more knowledge would be able to handle it much better.
On an UEFI boot if one tries the legacy memtest it gives error about DOS Magic Number, never tried the other combination..

Thanks.

Just as a piece of info. Was able to make a modified installition iso that will allow memtest 6.01 to run from legacy boot.
Used isomaster to add the memtest.leg and memtest.uefi files I copied from the mt86plus file. 
memtest.leg is memtest from legacy boot directory, and memtest.uefi is memtet from uefi directory.

I tried putting these files in both the boot directory or the /images directory, with using the correct path in grub.cfg modes.

With my regular grub4dos setup for my g4l project, the two different programs were linked to the boot?
grub4dos legacy would work with memtest.leg and grub4dos uefi boot would only work with the memtest.uefi.
With the Fedora ISO file, in legacy boot, it would run either program without issue..

Unfortunately, trying to boot in UEFI mode, the system would come up with a SHELL prompt rather than bringing up the grub menu.
Probable system is not liking that something is changed. 
Had tried modifying the grub.cfg under efi and got the shell.
Then tried not touching it, and just adding files to images directory and the /boot/grub2/grub.cfg, was hoping that it would bring up the 
UEFI boot menu, and I could manually edit an option, but ended up still having it just drop to shell.

Don't know if it might just be the ISO has a different name, in my testing made Fedmem.iso the Save as name, but it might be something in the ISO build
that is different, so it doesn't load menu??

Think the ISO use to include memtest before, so would usually run the memtest before doing an install. Would be nice to have it a part of install image.

In discussions on devel@ in the past, it's been suggested that a UEFI memtest86 package should be structured more or less like the shim-unsigned package in order to facilitate signing.

In case it's interesting, I've made a simple package that includes the SecureBoot patches that were merged upstream after 6.01:

https://github.com/gordonmessmer/memtest86--unsigned-x64

Questions: 
1. Link talks about 6.02 but checked site, and for me it still shows 6.01 as latest.
2. Recall earlier info that said, memtest wasn't signed for UEFI since they looked into it, and the cost was super high?
Are you talking about having Fedora/Redhat building memtest and using their key to sign it. 

Have a project G4L that I was able to make Legacy/UEFI boot using grub4dos boot loaders, but it of course doesn't work with secure boot set.
So, right now people have to turn it off, and then turn it back on afterwards.

Looked at link, and it has a lot of lines compared to mine very simple 20_memtest

Also, for info I used isomaster to modify the Fedora 37 iso install file.
put the memtest.leg and memtest.uefi files in /images directory.
added lines pointing to both in the /boot/grub2/grub.cfg file and testing under Virtual Box, with legacy boot, it would run either??
With grub4dos one must use the memtest.leg with legacy and memtest.uefi with the UEFI boot.

For some reason, doing a UEFI boot, brings up SHELL instead of showing the grub menu with UEFI as the original ISO works, so don't know if that is caused by making any mod to the image, or is that isomaster doesn't handle UEFI boot correctly. It seems to be old, and saved file is smaller than original..

Don't know if isomaster is still around. Found a page, and sent message, but no reply..

Will check if 6.02 version shows up for me, and test files from it once it does.
Thanks for info.

> 1. Link talks about 6.02 but checked site, and for me it still shows 6.01 as latest.

That's right.  SecureBoot support has been merged in the main branch, but there hasn't been a new release that includes the change.  When 6.02 is release, it'll have those patches.

> 2. Recall earlier info that said, memtest wasn't signed for UEFI since they looked into it, and the cost was super high?

I don't know where that idea came from.  memtest86+ couldn't have been signed for SecureBoot until there was a version that supported UEFI (which mean 6.0), and wasn't structured to provide space for a signature until https://github.com/memtest86plus/memtest86plus/pull/34 was merged.

Thanks for info, I will look on this rebase.

Merely for historical reference, pcmemtest (from which memtest86+ 6 was forked) was discussed here: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/TUEYTJ4YXOJ3GOSENLWAYMKPMXW23S2A/#ZSS4BPVRVFRDACJLEMYNKLZRZLA6LFBI

Releases retrieved: 6.10
Upstream release that is considered latest: 6.10
Current version/release in rawhide: 5.31-0.8.beta.fc38
URL: https://github.com/memtest86plus/memtest86plus

Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream.


Based on the information from Anitya: https://release-monitoring.org/project/1966/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/memtest86+

Scratch build failed. Details below:

BuilderException: Build failed:
Command '['rpmbuild', '-D', '_sourcedir .', '-D', '_topdir .', '-bs', '/var/tmp/thn-pucshwwj/memtest86+.spec']' returned non-zero exit status 1.

StdOut:
error: Bad source: ./memtest86+-6.10b.tar.gz: No such file or directory


Traceback:
  File "/usr/local/lib/python3.10/site-packages/hotness/use_cases/package_scratch_build_use_case.py", line 56, in build
    result = self.builder.build(request.package, request.opts)
  File "/usr/local/lib/python3.10/site-packages/hotness/builders/koji.py", line 188, in build
    raise BuilderException(

If you think this issue is caused by some bug in the-new-hotness, please report it on the-new-hotness issue tracker: https://github.com/fedora-infra/the-new-hotness/issues

Where are they getting the memtest86+6.10b.tar.gz or is that wrong name.

Download files are like 
https://memtest.org/download/v6.01/mt86plus_6.01_64.grub.iso.zip

So, it would seem that it would be 6.01 instead of 6.10?

I've taken the two memtest versions from the above iso, and used them in /boot as memtest.leg and memtest.uefi
and changed /etc/grub.d/20_memtest86+ to
# !/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry 'Memtest Legacy' {
	echo 'Loading memtest 6.01 for BIOS BOOT SYSTEM'
	linux /memtest.leg
}
menuentry 'Memtest UEFI' {
	echo 'Loading memtest 6.01 for UEFI BOOT SYSTEM'
	linux /memtest.uefi
}

Have no knowledge of creating rpm file.

*** Bug 2167082 has been marked as a duplicate of this bug. ***

While we are at it, is it too much to ask for Fedora to digitally sign the resulting UEFI binary? That would make it possible to use memtest86+ on EFI systems with secure boot enabled.

I've taken the work referenced here and created an updated RPM that combines everything discussed. Here are the scratch builds for further discussion:

rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=99304225
fedora-38: https://koji.fedoraproject.org/koji/taskinfo?taskID=99304252
fedora-37: https://koji.fedoraproject.org/koji/taskinfo?taskID=99304247

Tested:

* FAILS - Fedora 37 hardware UEFI secure boot enabled
* WORKS - Fedora 37 hardware UEFI
* WORKS - Fedora 38 hardware UEFI (MBP hardware, no secure boot)
* FAILS - Fedora 38 virtual UEFI secure boot enabled
* WORKS - Fedora 38 virtual UEFI
* WORKS - Fedora 38 virtual BIOS

Regarding getting secure boot working, the FPO would need to sign the uefi image as the shim currently rejects it when secure boot is enabled.

It's also worth noting that I didn't add automatic re-creation of the grub2 config. This could be added easily, but I was not certain of the right technique to add this to a scriptlet with current packaging policies. If it's okay to directly call grub2-mkconfig it's simple enough. 

%post and %postun seem appropriate: https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/

UEFI: `sudo grub2-mkconfig -o /etc/grub2-efi.cfg`
BIOS: `sudo grub2-mkconfig -o /etc/grub2.cfg`

*** Bug 1000322 has been marked as a duplicate of this bug. ***

Releases retrieved: 6.20
Upstream release that is considered latest: 6.20
Current version/release in rawhide: 5.31-0.8.beta.fc38
URL: https://github.com/memtest86plus/memtest86plus

Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream.


Based on the information from Anitya: https://release-monitoring.org/project/1966/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/memtest86+

Scratch build failed. Details below:

BuilderException: Build failed:
Command '['rpmbuild', '-D', '_sourcedir .', '-D', '_topdir .', '-bs', '/var/tmp/thn-w5jvj0mc/memtest86+.spec']' returned non-zero exit status 1.

StdOut:
warning: %patchN is deprecated (2 usages found), use %patch N (or %patch -P N)
setting SOURCE_DATE_EPOCH=1683417600
error: Bad file: ./memtest86+-6.20b.tar.gz: No such file or directory

RPM build warnings:
    %patchN is deprecated (2 usages found), use %patch N (or %patch -P N)

RPM build errors:
    Bad file: ./memtest86+-6.20b.tar.gz: No such file or directory


Traceback:
  File "/usr/local/lib/python3.11/site-packages/hotness/use_cases/package_scratch_build_use_case.py", line 56, in build
    result = self.builder.build(request.package, request.opts)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/hotness/builders/koji.py", line 225, in build
    raise BuilderException(

If you think this issue is caused by some bug in the-new-hotness, please report it on the-new-hotness issue tracker: https://github.com/fedora-infra/the-new-hotness/issues

Created attachment 1963067 [details]
Update to 6.20 (#2137395)

I've updated the proposed package to v6.20:

SPEC: https://jsteffan.fedorapeople.org/memtest/memtest86+.spec

rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=100950422
fedora-38: https://koji.fedoraproject.org/koji/taskinfo?taskID=100950454
fedora-37: https://koji.fedoraproject.org/koji/taskinfo?taskID=100950473

Tested v6.20 update:

* WORKS - Fedora 38 virtual UEFI (secure boot disabled)
* WORKS - Fedora 38 virtual BIOS

It's worth noting that this package does not work on ostree as a layered package. It would need to be installed in the main composed layer and I have not tested that yet.

Outstanding issues:

* Secure boot doesn't work; without signing the UEFI by the FPO this requires secure boot to be toggled off (can be toggled back on after running memtest)
* Package %scripts to automatically update grub config
* Review of the simplified configuration snippet for grub
* Location of shipped bins -- is there a better place now? I went with simple.
* Figure out correct way to enable this on ostree or maybe add a Conflicts for now

 %{forgeurl} is now deprecated.
Also today the guidelines patch to use %autorelease as recommended was merged.
So maybe drop the forge macros and switch to rpmautospec at the same time?

> Package %scripts to automatically update grub config

Please make the file name archful. There is only one architecture right now,
but there might be more in the future.

Also, the files should be somewhere under /usr, most likely /usr/lib/%{name}/.

The file in /boot should be installed via %posttrans, with kernel-install.

I've updated the package based on feedback received through multiple channels.

SPEC: https://jsteffan.fedorapeople.org/memtest/memtest86+.spec

rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=101074183
fedora-38: https://koji.fedoraproject.org/koji/taskinfo?taskID=101073068
fedora-37: https://koji.fedoraproject.org/koji/taskinfo?taskID=101074197

Tested v6.20 update:

* WORKS - Fedora 38 virtual UEFI x64 (secure boot disabled)
* WORKS - Fedora 38 virtual BIOS x64
* WORKS - Fedora 38 virtual BIOS ia32
* WORKS - Fedora 37 hardware UEFI x64 (secure boot disabled)

Changes:

* Ship artifacts archful
* Add ia32 in addition to x64
* Build the ISOs and ship in /usr/share
* Make bootloader configuration automatic and dynamic

I tried to coerce kernel-install and grubby into correctly installing these items. Unfortunately kernel-install looks too specialized for a kernel/initrd package right now. We should retry this technique after the UKI support is finalized. Even the kernel package doesn't use kernel-install for UKI right now. Grubby has similar issues (i.e. the templates really want an initrd it seems).

Outstanding issues:

* Secure boot doesn't work; I took a look at the kernel package and this seems straightforward enough -- we just need to find out policy on this
* Figure out correct way to enable this on ostree or maybe add a Conflicts for now -- this update wont install via rpm-ostree due to the new %scripts

(In reply to Zbigniew Jędrzejewski-Szmek from comment #27)
>  %{forgeurl} is now deprecated.

I was unable to find more details on the correct replacement for %{forgeurl}.

Changing over to rpmautospec will be done before committing these changes. `rpmautospec convert` will be used to extract the current changelog and switch to '%autochangelog'.

Source0: https://github.com/memtest86plus/memtest86plus/archive/v%{version}/memtest86-plus-%{version}.tar.gz

(In reply to Zbigniew Jędrzejewski-Szmek from comment #30)
> Source0:
> https://github.com/memtest86plus/memtest86plus/archive/v%{version}/memtest86-
> plus-%{version}.tar.gz

Ah, so just how it used to work. Is this change documented or announced somewhere?

I've updated the SPEC accordingly: https://jsteffan.fedorapeople.org/memtest/memtest86+.spec

I've updated the package based on more feedback.

SPEC: https://jsteffan.fedorapeople.org/memtest/memtest86+.spec

rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=101114219 
fedora-38: https://koji.fedoraproject.org/koji/taskinfo?taskID=101114232 
fedora-37: https://koji.fedoraproject.org/koji/taskinfo?taskID=101114245 

Tested after these changes (I had not yet tested booting the ISOs):

* WORKS - Fedora 38 virtual UEFI x64 (secure boot disabled)
* WORKS - Fedora 38 virtual BIOS x64
* WORKS - Fedora 37 hardware UEFI x64 (secure boot disabled)
* WORKS - BIOS ISO boot x64
* WORKS - BIOS ISO boot ia32
* FAILS - UEFI ISO boot x64
* FAILS - UEFI ISO boot ia32

Changes:

* Stop using ifarch to subpackage and simplify the package, subpackage spec is at: https://jsteffan.fedorapeople.org/memtest/ifarch-sub-package-memtest86+.spec
* Don't generate grub configuration, this could cause breakage if the system had been manually customized incorrectly, grub dynamic configuration spec is at: https://jsteffan.fedorapeople.org/memtest/isa-bits-multilib-memtest86+.spec
* Hack in a simple BLS (https://uapi-group.org/specifications/specs/boot_loader_specification/) config

Outstanding issues:

* Secure boot doesn't work, efi needs to be signed
* Figure out correct way to enable for ostree, we'll need to be completely out of /boot
* Find a better long-term solution for the BLS config (i.e. kernel-install)
* Get UEFI ISO booting working; I tested the grub-iso's and they also fail to boot UEFI, so rather than adding back in grub we should look at just fixing the UEFI booting for both and use the small non-grub ISO; no ix86 grub builds in Fedora anymore
* Grub menu ordering using the BLS loader entry; I tested the get_sorted_bls() function in /etc/grub.d/10_linux and it looks like what I've done should work... needs some more research
* To be able to repo install both x86_64 and i686 packages at the same time in x86_64 we'd need to add memtest86+ to some multilib allowlist... needs more research; the packages install side-by-side fine
* Last rpmlint error fix: memtest86+.i686: E: no-binary The package should be of the noarch architecture because it doesn't contain any binaries; oddly this doesn't happen in the memtest86+.x86_64 package

(In reply to Jonathan Steffan from comment #32)
[...]
> * To be able to repo install both x86_64 and i686 packages at the same time
> in x86_64 we'd need to add memtest86+ to some multilib allowlist... needs
> more research; the packages install side-by-side fine

You need to file a PR similar to this:
https://www.pagure.io/pungi-fedora/pull-request/1126

Been following these bug reports for some time, and much of it is beyond my knowledge, but do have some info in my use of memtest with my project.

I use the memtest programs I extract from the https://memtest.org/download/v6.20/mt86plus_6.20_64.grub.iso.zip
There is a memtest in the legacy directory and memtest in the uefi directory. 
My g4l project used pervious memtest versions with syslinux, and grub4dos legacy and grub4dos uefi.
rename the files to memtest.leg and memtest.uefi since grub4dos legacy only works with memtest.leg
and the grub4dos uefi only works with the memtest.uefi.
I've found that the fedora grub will work fine using either version without issue??
Don't know why.

Currently in my /boot directory have the old memtest86+-5.31 and the 6.20 files.
 149856 Jul 22  2022 memtest86+-5.31
 144344 May  8 08:00 memtest.leg
 145408 May  8 08:15 memtest.uefi

To create it, I modified the 20_memtest86+ to very simple. 

\# !/bin/sh
exec tail -n +3 $0
\# This file provides an easy way to add custom menu entries.  Simply type the
\# menu entries you want to add after this comment.  Be careful not to change
\# the 'exec tail' line above.
menuentry 'Memtest Legacy' {
	echo 'Loading memtest 6.20 for BIOS BOOT SYSTEM'
	linux /memtest.leg
}
menuentry 'Memtest UEFI' {
	echo 'Loading memtest 6.20 for UEFI BOOT SYSTEM'
	linux /memtest.uefi
}

That adds both options, and both seem to work identically? Only have 1 UEFI Fedora boot machine, so don't know if all would work.
So could just make on menuentry?? 

In grub4dos legacy menu.lst
title memtest 6.20
find --set-root /memtest.leg
kernel /memtest.leg

In grub4os uefi menu.lst
title memtest 6.20
find --set-root /memtest.uefi
kernel /memtest.uefi

Have a single 64M GPT partition that has both verions, so same usb can boot on legacy or uefi setup.
Have done testing with real systems, and with Virtual Box. 
As has been mentioned secure boot needs to be turned off or it fails.

Not clear on the i686, since know Fedora no longer does i686 releases? But the memtest files are self contained, so don't see them needing libraries?
Have used all the 6.x versions with no problems. Just use isomaster to extract each memtest file and rename them, and just copy them.

Once was directed to a mailing list on RPM creation, but turned out it was dead and had no traffic or people monitoring it.
Nice to see that work is being done. 
Might be worth something, or might just show how much I don't know about repos and rpm system.
Thanks.

(In reply to Jonathan Steffan from comment #32)
> * Get UEFI ISO booting working; I tested the grub-iso's and they also fail
> to boot UEFI, so rather than adding back in grub we should look at just
> fixing the UEFI booting for both and use the small non-grub ISO; no ix86
> grub builds in Fedora anymore

I've confirmed that the upstream ISOs also don't boot via UEFI currently when using TianoCore and gnome-boxes.

Tested booting these via gnome-boxes UEFI on F38:

* https://www.memtest.org/download/v6.20/mt86plus_6.20_64.iso.zip
* https://www.memtest.org/download/v6.20/mt86plus_6.20_64.grub.iso.zip

(In reply to Dominik 'Rathann' Mierzejewski from comment #33)
> You need to file a PR similar to this:
> https://www.pagure.io/pungi-fedora/pull-request/1126

Thanks. I've opened https://www.pagure.io/pungi-fedora/pull-request/1173

(In reply to Michael Setzer II from comment #34)
> Might be worth something, [...]

Thanks for the feedback. :-) Yes, your technique is completely valid. It's very similar to how I've approached this update. What I'd like to see is after installing `memtest86+` we've got a bootloader entry and something to boot. Wouldn't it be nice to just `dnf install memtest86+` and everything works? That's the goal at least.

Just to clarify. My system does add memtest boot options to the grub.cfg file..
Originally did it with 6.01, then 6.10, and now 6.20.

Have 5 Fedora machines in my room, so setup a file that I could copy and then use to install on the other 4.

Just updated for 6.20. Actually, now only need to copy the new memtest.* files and change the 6.10 to 6.20 in description.
But kept setup.

tar -tvf memtest6.20.xz
   416 2023-05-17 18:50 20_memtest86+
  1071 2023-05-17 18:57 Memtest6.20-Readme
144344 2023-05-08 08:00 memtest.leg
145408 2023-05-08 08:15 memtest.uefi
   294 2023-05-17 18:49 setupmemtest6.20.sh

20_memtest86+ (needs to be copied to the /etc/grub.d directory and chmod 755)
# !/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry 'Memtest Legacy' {
	echo 'Loading memtest 6.20 for BIOS BOOT SYSTEM'
	linux /memtest.leg
}
menuentry 'Memtest UEFI' {
	echo 'Loading memtest 6.20 for UEFI BOOT SYSTEM'
	linux /memtest.uefi
}

The Memtet6.20-readme has process to downlaod and extract files from site.

memtest.* are the two files one legacy and one uefi. With grub4dos has to match.
With grub either one seems to work fine.

setupmemtest6.20.sh was a script I wrote to do install on other machines after extracting files.
Have it rename existing file for backup, but not of much use.

# !/bin/sh
cp -p -v memtest.* /boot
if [ ! -f /etc/grub.d/20_memtest86+.org ] ; then 
	cp /etc/grub.d/20_memtest86+ /etc/grub.d/20_memtest86+.org
	chmod 644 /etc/grub.d/20_memtest86+.org
fi
cp 20_memtest86+ /etc/grub.d
chmod 755 /etc/grub.d/20_memtest86+
grub2-mkconfig -o /boot/grub2/grub.cfg


Copies the new file to /etc/grub.d and makes sure it is executible 
Then run the grub2-mkconfig to have it add new options to boot menu..

Seems to work fine with either memtest.leg or memtest.uefi, so could just pick one and have a single memtest setup.

So, process doesn't need dnf. Worked for my machines, but might not with other setups??
Good Luck. Have it working for my machines and with my g4l project. Thanks for replies.

(In reply to Michael Setzer II from comment #38)
> grub2-mkconfig -o /boot/grub2/grub.cfg

This is the command we should not run automatically. What if someone has changed their bootloader config? This could be a destructive action. Packages should not change user intent. See https://jsteffan.fedorapeople.org/memtest/isa-bits-multilib-memtest86+.spec 

There could be a situation where someone has changed the bootloader config and now we've overridden it by automatically calling `grub2-mkconfig`.

This package should be able to be installed without that risk.

Perhaps you know something that I don't??
I know on my systems the grub2-mkconfig is run on a number of things.
Believe the old previoius memtest 5.31 and before would prompt to actually run it after doing the setup manually rather than automatcially.
The link you provided actually includes grub2-mkconfig in the file??

Again, my knowledge on this is limited, but was under the impression it creates the grub.cfg file using the info from the /etc/grub.d directory.
So, not clear how changing the /etc/grub.d/20_memtest86+ file and running grub2-mkconfig would change anything else?
Could be if someone hand manually modified the grub.cfg file that something might be changed??

Don't know if you are talking about changing the actually boot loader from grub2 to something else? 
That probable would be an issue? Don't know if there is a method to check that grub2-mkconfig actually was used to create the previous grub.cfg.
Know that kernel upgrades have another grub?? program that is run, but normally running grub2-mkconfig just changes the grub.cfg.

Might be worth having it create a different filename with th grub2-mkconfig and then compare the files?
grub2-mkconfig -o /boot/grub2/grub.cfg.new
diff /boot/grub2/grub.cfg /boot/grub2.cfg.new

As example. I changed the /etc/grub.d/20_memtest86+ to have 6.20 versus the older 6.01.
Ran grub2-mkconfig -o /boot/grub2/grub.cfg.new
Generating grub configuration file ...
Found Windows 7 on /dev/sda2
Adding boot menu entry for UEFI Firmware Settings ...
done
[root@setzconote grub2]# diff grub.cfg grub.cfg.new 
203c203
< 	echo 'Loading memtest 6.01 for BIOS BOOT SYSTEM'
---
> 	echo 'Loading memtest 6.20 for BIOS BOOT SYSTEM'
207c207
< 	echo 'Loading memtest 6.01 for UEFI BOOT SYSTEM'
---
> 	echo 'Loading memtest 6.20 for UEFI BOOT SYSTEM'

Might be there is something I'm not seeing. 
I was looking for a solution that works, and for me at least this works for my Fedora 36 and 37 machines, and works in virtual box with syslinux, grub4dos, and grub4dos efi.
Make a 64M flash image that has grub4dos and grub4dos efi boot loaders and it runs the memtest with both. 

If there is something I don't see, please give me some info. Been doing the g4l since 2004, and lots of kernel builds over years, Originally 32 bit, but when Fedora dropped 32bit updates, had to figure move to 64bit. Then adding uefi required major modes to kernel build, which was a big issues, but only increased size by about 1/2M but hundreads of lines to config file. 

But might be something I have no clue about. Just that Fedora use to have full support for memtest and then it was broken.
Could get it to work if old boot using verion from memtest.org, but trying to install on eufi would say not supported at all. Even now it doesn't work with secure boot because of signing issue. Have same issue with my g4l project have to tell people if they have secure boot, will have to turn if off to use it, and then can turn it back on.

Use 40_custom to have my g4l added to the grub2 boot menu.
# !/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry G4L_Version_0.63_video_800x600 {
	set gfxpayload=800x600x16,800x600
	linux /bz6x3.2 root=/dev/ram0 telnetd=yes
	initrd /ramdisk.lzma
}

Just copy its kernel file and ramdisk.lzma files to /boot and use grub2-mkconfig

Thanks again for your time, and hopefully a fully supported official version will be out soon.
https://src.fedoraproject.org/rpms/memtest86+ still is talking about 5.31

(In reply to Jonathan Steffan from comment #35)
> I've confirmed that the upstream ISOs also don't boot via UEFI currently
> when using TianoCore and gnome-boxes.
> 
> Tested booting these via gnome-boxes UEFI on F38:
> 
> * https://www.memtest.org/download/v6.20/mt86plus_6.20_64.iso.zip
> * https://www.memtest.org/download/v6.20/mt86plus_6.20_64.grub.iso.zip

Upstream ticket opened to work on this in the right location: https://github.com/memtest86plus/memtest86plus/issues/311

FEDORA-2023-9582d6d73d has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-9582d6d73d

FEDORA-2023-b076116ab6 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-b076116ab6

Don't know if you are loading the iso or the memtest programs.

Way to extract the memtest programs from ISO file.
ISO file is 20M while memtest programs are about 145K each.

cat getmemtest.sh 
mount -o loop Downloads/mt86plus_6.20_64.grub.iso /mnt
cp /mnt/boot/memtest memtest.leg -p -v
cp /mnt/EFI/BOOT/memtest memtest.uefi -p -v
umount /mnt

cp memtest.* to /boot
modify the /etc/grub.d file below and grub2-mkconfig.


20_memtest86+ (needs to be copied to the /etc/grub.d directory and chmod 755)
# !/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry 'Memtest Legacy' {
	echo 'Loading memtest 6.20 for BIOS BOOT SYSTEM'
	linux /memtest.leg
}
menuentry 'Memtest UEFI' {
	echo 'Loading memtest 6.20 for UEFI BOOT SYSTEM'
	linux /memtest.uefi
}

FEDORA-2023-b076116ab6 has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-b076116ab6`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-b076116ab6

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-9582d6d73d has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-9582d6d73d`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-9582d6d73d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

(In reply to Michael Setzer II from comment #44)

> # !/bin/sh
> exec tail -n +3 $0
> # This file provides an easy way to add custom menu entries.  Simply type the
> # menu entries you want to add after this comment.  Be careful not to change
> # the 'exec tail' line above.
> menuentry 'Memtest Legacy' {
> 	echo 'Loading memtest 6.20 for BIOS BOOT SYSTEM'
> 	linux /memtest.leg
> }
> menuentry 'Memtest UEFI' {
> 	echo 'Loading memtest 6.20 for UEFI BOOT SYSTEM'
> 	linux /memtest.uefi
> }

There is a bug at: https://src.fedoraproject.org/rpms/memtest86+/blob/rawhide/f/memtest86+.spec#_71
leading "/boot" is missing, it should be "linux /boot/memtest86+%{mt_isa}.bin"

(In reply to Xose Vazquez Perez from comment #47)

> (In reply to Michael Setzer II from comment #44)
> 
> > # !/bin/sh
> > exec tail -n +3 $0
> > # This file provides an easy way to add custom menu entries.  Simply type the
> > # menu entries you want to add after this comment.  Be careful not to change
> > # the 'exec tail' line above.
> > menuentry 'Memtest Legacy' {
> > 	echo 'Loading memtest 6.20 for BIOS BOOT SYSTEM'
> > 	linux /memtest.leg
> > }
> > menuentry 'Memtest UEFI' {
> > 	echo 'Loading memtest 6.20 for UEFI BOOT SYSTEM'
> > 	linux /memtest.uefi
> > }
> 
> There is a bug at:
> https://src.fedoraproject.org/rpms/memtest86+/blob/rawhide/f/memtest86+.
> spec#_71
> leading "/boot" is missing, it should be "linux
> /boot/memtest86+%{mt_isa}.bin"

Also at: https://src.fedoraproject.org/rpms/memtest86+/blob/rawhide/f/memtest86+.spec#_66

(In reply to Xose Vazquez Perez from comment #47)
> 
> There is a bug at:
> https://src.fedoraproject.org/rpms/memtest86+/blob/rawhide/f/memtest86+.
> spec#_71
> leading "/boot" is missing, it should be "linux
> /boot/memtest86+%{mt_isa}.bin"

That depends on the presence of a separate boot partition. During testing I also had to add /boot to the path stored in the BLS snippet, but only for machines without separate boot partition (which is a deviation from Fedora default configuration).

(In reply to Norbert Jurkeit from comment #49)

> That depends on the presence of a separate boot partition. During testing I
> also had to add /boot to the path stored in the BLS snippet, but only for
> machines without separate boot partition (which is a deviation from Fedora
> default configuration).

The correct one is the "absolute path".

And the kernel uses it:
# grep ^linux -h /boot/loader/entries/*
linux /boot/vmlinuz-0-rescue-9fe3fd3af37144199cf2cf54e2bca4ed
linux /boot/vmlinuz-6.2.16-300.fc38.x86_64
linux /boot/vmlinuz-6.3.3-200.fc38.x86_64

(In reply to Xose Vazquez Perez from comment #50)

> And the kernel uses it:
> # grep ^linux -h /boot/loader/entries/*
> linux /boot/vmlinuz-0-rescue-9fe3fd3af37144199cf2cf54e2bca4ed
> linux /boot/vmlinuz-6.2.16-300.fc38.x86_64
> linux /boot/vmlinuz-6.3.3-200.fc38.x86_64

Try that on a machine with default partitioning (i.e. separate boot partition) and you will see something like that:
# grep ^linux -h /boot/loader/entries/*
linux /memtest86+x64.efi
linux /vmlinuz-0-rescue-08cd084e7c184adb8a7e768eb8c9b83d
linux /vmlinuz-6.2.12-300.fc38.x86_64
...

On another machine without separate boot partition but with / on BTRFS subvolume "root" I even get:
# grep ^linux -h /boot/loader/entries/*
linux /root/boot/memtest86+x64.bin
linux /root/boot/vmlinuz-0-rescue-83b314d6a13a4d028e0d2f1f7ed51ece
linux /root/boot/vmlinuz-6.2.15-300.fc38.x86_64
...

The kernel snippets were created automatically this way, the memtest snippet in the last example had to be modified to work. The memtest package would ideally use the same elaborate mechanism as the kernel updates, but I don't know whether this is feasible.

I've disabled the auto-push for both updates until I can sort out the best approach for the BLS. I was hoping that going with the default Fedora installer layout would be good enough, but obviously that is not the case.

Updates:

* The ISOs do boot UEFI correctly, when secureboot is disabled (re: https://github.com/memtest86plus/memtest86plus/issues/311)

Outstanding Issues:

* Use more advanced technique to add the BLS and support more filesystem layouts by default (i.e. kernel-install, grubby, or something like it)
* Figure out BLS ordering in grub's implementation (i.e. /etc/grub.d/10_linux) so the entry is not at the top https://uapi-group.org/specifications/specs/boot_loader_specification/#sorting

I've started on a kernel-install plugin to install for grub and systemd-boot based installs. This plugin will not be ran by default, but rather called with `KERNEL_INSTALL_PLUGINS=` set to exclusively define only this plugin. So far, it works for grub based systems and I'll be adding systemd-boot support soonish.

Okay, here are scratch builds to test out the kernel-install plugin approach with supporting more than just the default layout. Please uninstall memtest86+ and then install this build. I've tested fresh install and uninstall using the default Fedora layout. Before moving forward with supporting systemd-boot, I'd like to get this working and released.

rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=101817422
f38: https://koji.fedoraproject.org/koji/taskinfo?taskID=101817427
f37: https://koji.fedoraproject.org/koji/taskinfo?taskID=101817431

Updates:

* Use a kernel-install plugin to add/remove the appropriate BLS entries and manage the boot filesystem

Tested:

* F38 BIOS/UEFI fresh install & removal on default layout
* GRUB menu ordering fixed for both blscfg loaded entries and get_sorted_bls loaded entries

Outstanding Issues:

* Add in memtest86+-6.20-1 -> memtest86+-6.20-2 update cleanup
* Validating more than the default Fedora boot layout, help here is very appreciated

F37 kernel-install doesn't support using `KERNEL_INSTALL_PLUGINS=`. I'll look at adding a versioned Requires to guard against this and try out a few things to get around this.

memtest86+-6.20-2.fc38.x86_64.rpm works as expected on my F38 installations (all with grub2 and BLS):
1. UEFI with default layout
2. UEFI without boot partition and / on Ext4
3. UEFI without boot partition and / on Btrfs subvolume
4. BIOS without boot partition and / on Ext4

It is also nice to have the memtest86+ entry no longer displayed at the top of the grub menu.

I also tried memtest86+-6.20-2.fc37.x86_64.rpm on a F37 installation but that gave me strange error messages and a broken kernel related BLS snippet. Personally I wouldn't put too much effort into this and consider a notice for non-standard disk layouts in the package description as sufficient.

Question on differences between 5.31 rpm and 6.20 rpm?

rpm -qlpv memtest86+-5.31-0.7.beta.fc37.x86_64.rpm | cut -b48-200
 151452 Jul 22  2022 /boot/elf-memtest86+-5.31
 149856 Jul 22  2022 /boot/memtest86+-5.31
      0 Jul 22  2022 /etc/grub.d/20_memtest86+
    424 Jul 22  2022 /etc/memtest86+.conf
   2300 Jul 22  2022 /usr/sbin/memtest-setup
      0 Jul 22  2022 /usr/share/doc/memtest86+
  36356 Jul 22  2022 /usr/share/doc/memtest86+/README
   3284 Jul 22  2022 /usr/share/doc/memtest86+/README.fedora
    472 Jul 22  2022 /usr/share/man/man8/memtest-setup.8.gz
      0 Jul 22  2022 /usr/share/memtest86+
   4136 Jul 22  2022 /usr/share/memtest86+/20_memtest86+

rpm -qlpv memtest86+-6.20-1.fc37.x86_64.rpm | cut -b47-200
  144344 May 19 11:20 /usr/lib64/memtest86+/memtest86+x64.bin
  145408 May 19 11:20 /usr/lib64/memtest86+/memtest86+x64.efi
       0 May 19 11:20 /usr/share/doc/memtest86+
   26885 May  8 00:55 /usr/share/doc/memtest86+/README.md
       0 May 19 11:20 /usr/share/licenses/memtest86+
   18092 May  8 00:55 /usr/share/licenses/memtest86+/LICENSE
 6193152 May 19 11:20 /usr/share/memtest86+/memtest86+x64.iso

As I understand the 5.31 installation, the rpm actually places the support files in locations, and it actually the memtest-setup that actually creates the /etc/grub.d/20_memtest86+ file and then requires running the grub2-mkconfig to actually build it into the grub.cfg.
Using the level 20_ it always places it later then kernels. For my g4l project I use a 40_custom that puts it further down list.

The 6.20 rpm again places files in directories other than the /boot or grub directories. So must be using some other option to install it in grub.cfg.
Also note that it has the ISO file but also has the .bin and .efi files. The ISO file is over 6M versus the about 290K for the .bin and .efi.

Again, don't know about the rpm installation  process and probable the /usr/share/ files are a nice addition?

I've made a simple script that uses a different method to get the latest files directly from memtest86+ site and create a very very simple 20_memtest86+ file.

script getmemtest5.sh (no pretty and put the boot variable to try to find boot locaton if boot or some other location. Don't fully understand all the other possible locations?)
 
\#!/usr/bin/bash
cd /tmp
mkdir memtest
cd memtest
rm index.html -f
wget https://memtest.org/ 
f=$(grep download <index.html | grep binaries.zip | sed 's/[ \t]//g'|cut -f2 -d\" |head -n 1)
rm index.html -f
wget -nc https://memtest.org/$f
echo $f
zip=$(echo $f | cut -f4 -d/)
unzip -u $zip
boot=$(find / -maxdepth 2 -iname loader | sed 's_/loader__')
cp memtest64.bin $boot/memtest.leg -p -v
cp memtest64.efi $boot/memtest.uefi -p -v
ver=$(echo $zip | cut -b10-13);
{
printf "# \x21/bin/sh\nexec tail -n +3 \$0\n# This file provides an easy way to add custom menu entries.  Simply type the\n";
printf "# menu entries you want to add after this comment.  Be careful not to change\n# the 'exec tail' line above.\n" ;
printf "menuentry 'Memtest Legacy' {\n	echo 'Loading memtest $ver for BIOS BOOT SYSTEM'\n	linux /memtest.leg\n}" ;
printf "\nmenuentry 'Memtest UEFI' {\n	echo 'Loading memtest $ver for UEFI BOOT SYSTEM'\n	linux /memtest.uefi\n}\n";  } >/etc/grub.d/20_memtest86+
chmod 755 /etc/grub.d/20_memtest86+

Script downloads the index.html file from the memtest.org site and locates the link to path. Use /tmp/memtest directory to get files
Then unzips the file to get the binary files
Then copy the memtest64.bin and memtet64.efi to the names I've been using memtet.leg (legacy) and memtet.uefi.
Extracts the version number (6.20 at moment) so 20_memtest86+ will contain latest verion number.
The creates the 20_memtest86+ file, and makes it executible.

Would then need to run grub2-mkconfig to actually create a new grub.cfg file.

As I've memtioned before. Fedora's grub2 setup seems to work fine with either .bin or .efi version of memtest, unlike grub4dos that only works with the matching version for legacy or uefi.
Probable a lot of things that could be done to make script cleaner, but this seems to work. Will have to see if it handles next update.
Just depends if one trusts the memtest site, and not clear on mention of some patches??

Ideally, it would be nice to have a version of efi file that was signed so that it would work with secure boot, but that doesn't seem to be an option.

Perhaps I am missing something.
Thanks again for all the work.

(In reply to Norbert Jurkeit from comment #56)
> memtest86+-6.20-2.fc38.x86_64.rpm works as expected on my F38 installations
> (all with grub2 and BLS):
[...]

Thanks for testing.

> I also tried memtest86+-6.20-2.fc37.x86_64.rpm on a F37 installation but
> that gave me strange error messages and a broken kernel related BLS snippet.

Yes, the memtest86+-6.20-2.fc37.x86_64.rpm is broken and should not be used. Due to kernel-install not supporting `KERNEL_INSTALL_PLUGINS=` the default plugins are ran and fail to work. It will also likely set memtest86+ to default booting, which obviously is wrong.

To clean up:

* Manually select previous kernel, if you had rebooted and memtest86+ was set to default boot
* Remove memtest86+-6.20-2.fc37 without running scripts: `rpm -e --noscripts memtest86+`
* Remove "/boot/memtest86+x64.efi-6.20" and "/boot/loader/entries/$(cat /etc/machine-id)-6.20.conf"

(In reply to Michael Setzer II from comment #57)
> Question on differences between 5.31 rpm and 6.20 rpm?
[...]

Yes, with this update we are changing the layout to better support multiple bootloaders and system configurations. The Fedora rpm builds memtest86+ from source and puts the results in appropriate locations on the filesystem. There are then rpm scripts defined in the rpm to deal with copying files to the correct location for the running system configuration and generating a bootloader configuration snippet that is dynamically loaded.

> Ideally, it would be nice to have a version of efi file that was signed so
> that it would work with secure boot, but that doesn't seem to be an option.

We will address this in a future update if it's approved. The whole boot infrastructure is in flux and undergoing improvements.[1][2][3][4][much more going on...]

1. https://fedoraproject.org/wiki/Changes/BiggerESP https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/B4UAREAUA3TBR64ZVCAQLMR57AGGJ3YJ/
2. https://fedoraproject.org/wiki/Changes/mkosi-initrd
3. https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1 https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_2
4. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/N6NR4Q6SNZ4MICDYYLBMWIRCONM7ZREU/

FEDORA-2023-d045ed2bb6 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-d045ed2bb6

FEDORA-2023-d045ed2bb6 has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-d045ed2bb6`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-d045ed2bb6

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-1d664ec3c2 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-1d664ec3c2

The F37 build now also uses the plugin, but calls it directly. The F37 systemd version (251) of kernel-install doesn't support `KERNEL_INSTALL_PLUGINS=` so I just hacked in the variables from `kernel-install inspect`. It's nasty, but it does work. I chose to not get fancy with the shell code, but if anyone has a major objection or improvement they are willing to contribute please let me know.

At this point, I'm expecting that all testing updates will be pushed to stable before the end of the month. Thanks for any additional testing.

FEDORA-2023-1d664ec3c2 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-1d664ec3c2`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-1d664ec3c2

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Good to see things are being done, but don't have a clue what the kernel_install_plugins is for?
The system I use to run the memtest 6.20 just loads the 140K file, with nothing fancy.

In grub.cfg
### BEGIN /etc/grub.d/20_memtest86+ ###
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry 'Memtest Legacy' {
	echo 'Loading memtest 6.20 for BIOS BOOT SYSTEM'
	linux /memtest64.bin
}
menuentry 'Memtest UEFI' {
	echo 'Loading memtest 6.20 for UEFI BOOT SYSTEM'
	linux /memtest64.efi
}
### END /etc/grub.d/20_memtest86+ ###

Just modified /etc/grub.d/20_memtest86+ and have grub2-mkconfig do the creation.

Does this update actually load a kernel file and then call the memtest?
If so, does that mean it doesn't test that area of ram?
Believe memtest use to load itself into ram, and run the memory test on the rest of ram, and then later it would move itself in ram, and then run test on that previous errors.
Know this official process seems to be much more complex.
Am hoping they will release an updated version to test if my process will work with an update. Have used it past version changes, but manually changed process.

Thanks for the work.

FEDORA-2023-a11d2957c5 has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-a11d2957c5`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-a11d2957c5

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-d8a6f1c744 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-d8a6f1c744`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-d8a6f1c744

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Downloaded the rpm file and extracted the contents.
Just looking at the install script, a lot I don't follow.

Looks like it contains files and then seems it puts them under usr/
then script copies files to grub directory(s)??

dnf install memtest86+* --downloadonly --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-d8a6f1c744
downloads
/var/cache/dnf/updates-testing-77f7a183e9a6bed9/packages/memtest86+-6.20-3.fc37.x86_64.rpm

Move file to another directory and run
rpm2cpio memtest86+-6.20-3.fc37.x86_64.rpm | cpio -idmv
./usr/lib64/memtest86+/memtest86+.kernel-install-plugin
./usr/lib64/memtest86+/memtest86+x64.bin
./usr/lib64/memtest86+/memtest86+x64.efi
./usr/share/doc/memtest86+
./usr/share/doc/memtest86+/README.md
./usr/share/licenses/memtest86+
./usr/share/licenses/memtest86+/LICENSE
./usr/share/memtest86+/memtest86+x64.iso
12759 blocks

Mounting the iso file as loop. Physical size shows as 6M
6193152 Jul  5 07:48 memtest86+x64.iso

While contents seems much smaller?

du . | sort -n
144	./EFI/BOOT
146	./EFI
1442	./boot
1592	.


ls -lR
.:
total 6
drwxr-xr-x. 2048 Jul  5 07:48 boot
-r--r--r--. 2048 Jul  4 10:00 boot.catalog
drwxr-xr-x. 2048 Jul  5 07:48 EFI

./boot:
total 1440
-rw-r--r--. 1474560 Jul  5 07:48 floppy.img

./EFI:
total 2
drwxr-xr-x. 2048 Jul  5 07:48 BOOT

./EFI/BOOT:
total 142
-rwxr-xr-x. 145408 Jul  5 07:48 bootx64.efi
[root@setzconote mnt]# 

Perhaps I'm not seeing something??
Interesting though...


the two memtest+x64 files don't match ones from site, so assume the are compiled from source??




Wondering if some other program like grub2-mkconfig or installing a newer kernel would have these changes remain, or would then require reinstallation?

(In reply to Michael Setzer II from comment #68)
> Looks like it contains files and then seems it puts them under usr/
> then script copies files to grub directory(s)??

Yes, that is correct.

> Mounting the iso file as loop. Physical size shows as 6M
> 6193152 Jul  5 07:48 memtest86+x64.iso
> 
> While contents seems much smaller?

The bootloader/ESP on the ISO itself is a lot of the ISO payload. In this case, the following commands are used to create the ISO (as part of calling the upstream Makefile):

memtest.iso: memtest.mbr floppy.img esp.img
	@mkdir -p iso/boot
	cp floppy.img iso/boot/floppy.img
	xorrisofs -pad -R -J -volid MT86PLUS_64 -graft-points -hide-rr-moved --grub2-mbr memtest.mbr \
		  -b /boot/floppy.img --efi-boot --interval:appended_partition_2:all:: \
		  -part_like_isohybrid -iso_mbr_part_type 0x00 -append_partition 2 0xef ./esp.img \
		  -o ./memtest.iso /boot=./iso/boot /EFI=./iso/EFI

> Interesting though... the two memtest+x64 files don't match ones from site, so assume the are
> compiled from source??

Correct, everything is compiled from source.

> Wondering if some other program like grub2-mkconfig or installing a newer
> kernel would have these changes remain, or would then require reinstallation?

The BLS configuration is dynamically loaded by GRUB at boot time and nothing will need to be reinstalled or changed after running `grub2-mkconfig` or installing a new kernel.

(In reply to Michael Setzer II from comment #65)
> Good to see things are being done, but don't have a clue what the
> kernel_install_plugins is for?

This change is to support managing bootable stuff in a new common way across multiple bootloaders and filesystem layouts. I agree it's awkward to be using a kernel install utility for this right now, but that is why I've added a plugin to do what is needed for this use-case. I'm confident all of this plumbing will become more generic over time. The UKI stuff is first that needs to get working.[1]

I've already ran into awkwardness using `kernel-install` and that is why memtest86+-6.20-3 has been added to updates-testing. Lots to do here to make it better.

> Does this update actually load a kernel file and then call the memtest?

Good question. No, this does not load a kernel and all areas of RAM are tested like normal. All this does is use the `kernel-install` utility with a plugin to create a BLS[2] configuration file and copy the bits to the detected bootable location. In the Fedora GRUB, this configuration file is then read at boot time and provides the needed menu entry.

1. https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1 https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_2
2. https://uapi-group.org/specifications/specs/boot_loader_specification/

Unfortunately the updated kernel-install in rawhide has what appears to be a new behavior. I'll investigate more and update the plugin as needed.

The kernel-install command is now putting the BLS and EFI image in /boot/efi/ on an existing install that has everything already located in /boot:

[root@fedora ~]# ls -1 /boot{/,/loader/entries}
/boot/:
config-6.5.0-0.rc0.20230706gitc17414a273b8.12.fc39.x86_64
config-6.5.0-0.rc2.17.fc39.x86_64
config-6.5.0-0.rc2.20230721gitf7e3a1bafdea.20.fc39.x86_64
efi
grub2
initramfs-0-rescue-3e6116f95cf6443bab7d729e6e596ff5.img
initramfs-6.5.0-0.rc0.20230706gitc17414a273b8.12.fc39.x86_64.img
initramfs-6.5.0-0.rc2.17.fc39.x86_64.img
initramfs-6.5.0-0.rc2.20230721gitf7e3a1bafdea.20.fc39.x86_64.img
loader
lost+found
symvers-6.5.0-0.rc0.20230706gitc17414a273b8.12.fc39.x86_64.xz
symvers-6.5.0-0.rc2.17.fc39.x86_64.xz
symvers-6.5.0-0.rc2.20230721gitf7e3a1bafdea.20.fc39.x86_64.xz
System.map-6.5.0-0.rc0.20230706gitc17414a273b8.12.fc39.x86_64
System.map-6.5.0-0.rc2.17.fc39.x86_64
System.map-6.5.0-0.rc2.20230721gitf7e3a1bafdea.20.fc39.x86_64
vmlinuz-0-rescue-3e6116f95cf6443bab7d729e6e596ff5
vmlinuz-6.5.0-0.rc0.20230706gitc17414a273b8.12.fc39.x86_64
vmlinuz-6.5.0-0.rc2.17.fc39.x86_64
vmlinuz-6.5.0-0.rc2.20230721gitf7e3a1bafdea.20.fc39.x86_64

/boot/loader/entries:
3e6116f95cf6443bab7d729e6e596ff5-0-rescue.conf
3e6116f95cf6443bab7d729e6e596ff5-6.5.0-0.rc0.20230706gitc17414a273b8.12.fc39.x86_64.conf
3e6116f95cf6443bab7d729e6e596ff5-6.5.0-0.rc2.17.fc39.x86_64.conf
3e6116f95cf6443bab7d729e6e596ff5-6.5.0-0.rc2.20230721gitf7e3a1bafdea.20.fc39.x86_64.conf
[root@fedora ~]# ls -1 /boot/efi{/,/loader/entries}
/boot/efi/:
EFI
loader
mach_kernel
memtest86+x64.efi
System

/boot/efi/loader/entries:
3e6116f95cf6443bab7d729e6e596ff5-0-memtest86+.conf

This does not affect BIOS systems. Only UEFI systems with systemd-udev-254~rc2-4.fc39.x86_64+ installed will see this issue.

FEDORA-2023-a1d175f33b has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-a1d175f33b

FEDORA-2023-a1d175f33b has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2023-d453c66058 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-d453c66058

FEDORA-2023-4b8bbb8ca1 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-4b8bbb8ca1

FEDORA-2023-d453c66058 has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-d453c66058`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-d453c66058

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-4b8bbb8ca1 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-4b8bbb8ca1`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-4b8bbb8ca1

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Question on initrd in entry??

Did a test install and this was created in /boot/loader/entries
cat bd97d9dfc2d04f1cb050aff929929ddf-0-memtest86+.conf 
title Memtest86+ (memtest86+x64.bin-6.20)
version 0-6.20-memtest86+
linux /memtest86+x64.bin
grub_users $grub_users
grub_arg --unrestricted
grub_class fedora

So, created a script on another machine to just create a similar entry.
cat 189711f94e78436d9618b891a8fce70e-0-Memtest86.conf 
title Memtest86+ (6.20)
version 0-Memtest-189711f94e78436d9618b891a8fce70e
linux /memtest64.bin
grub_users $grub_users
grub_arg --unrestricted
grub_class fedora

Script is  (Just copied output to entry and added (6.20)
machineid=$(cat /etc/machine-id) 

echo title Memtest86+
echo version 0-Memtest-$machineid
echo linux /memtest64.bin
echo grub_users \$grub_users
echo grub_arg --unrestricted
echo grub_class fedora

Rebooted machine, and entry was added, but I used the edit option, the then ctrl-X to run it, and it prompted for initrd expecting file?
Might be that it I used it without the edit option the error would not come up?? But just pressing enter did bring it up.
Looks like this would probable be better approach the the other option to add entry. 
Again, thanks for the work. Would be nice to have it working in the native fedora setup.

Just for follow up on initrd issue?

Did a test with running without edit and still got message about initrd should have file.
Created a simple blank.lzma file using
touch blank
lzma blank
Contains 5D 00 00 80  00 FF FF FF  FF FF FF FF  FF 00 83 FF  FB FF FF C0  00 00 00
Put the file in /boot

Then have initrd /blank.lzma in entry and error is not shown.
I'm using Fedora 37, so don't know if this happens on others?

My latest script to get latest files from memtest.org and setup the entry is now.
#!/usr/bin/bash
clear
mkdir -p /tmp/memtest
cd    /tmp/memtest || exit
f=$(wget -O - https://memtest.org/ 2>/dev/null | grep -m1 binaries.zip | sed -e 's/.*<a href="//' -e 's/".*//')
if [ -z "$f" ]
then
  echo "Unable to get pathname for binaries.zip" >&2
  exit 1
fi
wget -nc https://memtest.org/"$f"
echo "$f"
zip=$(echo "$f" | cut -f4 -d/)
unzip -u "$zip"
boot=$(find / -maxdepth 2 -iname loader | sed 's_/loader__')
if [ -z "$boot" ]
then
  boot="/boot";
fi
echo $boot
cp memtest64.* "$boot" -p -v
ver=$(echo "$zip" | cut -b10-13);

machineid=$(cat /etc/machine-id) 

{
echo title Memtest86+ \($ver\)
echo version 0-"$ver"-memtest86+
echo linux /memtest64.bin
echo initrd /blank.lzma
echo grub_users \$grub_users
echo grub_arg --unrestricted
echo grub_class fedora
} >/boot/loader/entries/$machineid-0-Memtest86+.conf

cd /boot
if [ ! -f blank.lzma ]
then
  touch blank
  lzma blank
fi

(In reply to Michael Setzer II from comment #78)
> Rebooted machine, and entry was added, but I used the edit option, the then
> ctrl-X to run it, and it prompted for initrd expecting file?
> Might be that it I used it without the edit option the error would not come
> up?? But just pressing enter did bring it up.

I've tested editing the menu entry using grub 2.06 on F37, F38, and rawhide (UEFI & BIOS) and have not been able to reproduce a required initrd to boot.

For a default Fedora system layout, the menu entry generated by the BLS is:

load_video
set gfxpayload=keep
insmod gzio
linux ($root)/memtest86+x64.efi

In my comment 79 above I just created an emtpy file with 0 bytes, and then converted it to a lzma file.
Might be possible to use a blank file, but know that an lzma file works.

So on my noteboot it creates
cat 189711f94e78436d9618b891a8fce70e-0-Memtest86+.conf 
title Memtest86+ (6.20)
version 0-6.20-memtest86+
linux /memtest64.bin
initrd /blank.lzma
grub_users $grub_users
grub_arg --unrestricted
grub_class fedora

That boots with no message about the initrd file missing.

(In reply to Michael Setzer II from comment #81)
> In my comment 79 above I just created an emtpy file with 0 bytes, and then
> converted it to a lzma file.
> Might be possible to use a blank file, but know that an lzma file works.
> 
> So on my noteboot it creates
> cat 189711f94e78436d9618b891a8fce70e-0-Memtest86+.conf 
> title Memtest86+ (6.20)
> version 0-6.20-memtest86+
> linux /memtest64.bin
> initrd /blank.lzma
> grub_users $grub_users
> grub_arg --unrestricted
> grub_class fedora
> 
> That boots with no message about the initrd file missing.

So if you remove "initrd /blank.lzma" the entry will not boot at all? What version of grub do you have installed on your MBR?

No, it pops up with a message saying initrd is blank.
If I don't add the initrd /blank.lzma the grub entry puts an empty one.

title Memtest86+ (6.20)
version 0-6.20-memtest86+
linux /memtest64.bin
initrd 
grub_users $grub_users
grub_arg --unrestricted
grub_class fedora

Even though the entry doesn't have the line.
title Memtest86+ (6.20)
version 0-6.20-memtest86+
linux /memtest64.bin
grub_users $grub_users
grub_arg --unrestricted
grub_class fedora

So grub must be inserting a initrd line on its own if missing.
Pressing Enter after the error message has it load and run fine, its just a 
process that removes the error message, and having to press enter key to bypass it.

I've requested pushed the pending updates for F37 and F38 to stable. F39+ has already been updated.

FEDORA-2023-d453c66058 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2023-4b8bbb8ca1 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.

Just ran dnf update and it upgraded the 5.31 to the 6.20 on my Fedora 37 machine.
Comparing the manual entry I had created with the one just installed by update.

The one just installed creates this entry.

cat 189711f94e78436d9618b891a8fce70e-0-memtest86+.conf 
title Memtest86+ (memtest86+x64.bin-6.20)
version 0-6.20-memtest86+
linux /memtest86+x64.bin
grub_users $grub_users
grub_arg --unrestricted
grub_class fedora


The one I manually created is mostly the same, except I use file directly from website rather than building on from source.
I also added an initrd line pointing to a blank.lzma (lzma of empty blank file). Was getting a message about missing initrd file.

# cat 189711f94e78436d9618b891a8fce70e-0-Memtest86+.conf 
title Memtest86+ (6.20)
version 0-6.20-memtest86+
linux /memtest64.bin
initrd /blank.lzma
grub_users $grub_users
grub_arg --unrestricted
grub_class fedora


# diff 189711f94e78436d9618b891a8fce70e-0-Memtest86+.conf 189711f94e78436d9618b891a8fce70e-0-memtest86+.conf 
1c1
< title Memtest86+ (6.20)
---
> title Memtest86+ (memtest86+x64.bin-6.20)
3,4c3
< linux /memtest64.bin
< initrd /blank.lzma
---
> linux /memtest86+x64.bin

Files in boot (two are same size, but not 100% same).
144344 May  7 17:06 memtest64.bin
145408 May  7 17:06 memtest64.efi
144344 Aug  4 11:40 memtest86+x64.bin

See memtest version 7.00 has been released.