Releases retrieved: 6.00 Upstream release that is considered latest: 6.00 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-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/