search

dakanji / RefindPlus

A Boot Manager for Mac and PC
GNU General Public License v3.0
333 stars 66 forks source link

RefindPlus does not detect MemTest #166

Closed birdie-github closed 1 year ago

birdie-github commented 1 year ago

RefindPlus Version

v0.14.0.AA Release

Device Type

UEFI PC

Problem Description

Here's my efi/memtest:

drwxr-xr-x. 3 root root    4096 Jul 13 10:18 .
drwxr-xr-x. 8 root root    4096 Jul 14 06:15 ..
drwxr-xr-x. 2 root root    4096 Jun 11  2019 benchmark
-rw-r--r--. 1 root root    5731 Jun 19 01:12 blacklist.cfg
-rw-r--r--. 1 root root 1612472 Jun 19 01:12 BOOTX64.efi
-rw-r--r--. 1 root root    1374 Oct  6  2021 customtests.cfg
-rw-r--r--. 1 root root    1808 Apr 18 23:12 mt86.cfg
-rw-r--r--. 1 root root    1186 Feb  9  2021 mt86foot.htm
-rw-r--r--. 1 root root     550 Oct  6  2021 mt86head.htm
-r--r--r--. 1 root root    6823 Sep  5  2015 mt86.png
-rw-r--r--. 1 root root   21516 Jun 19 01:12 report.css
-rw-r--r--. 1 root root    1566 Feb  9  2021 SPD.spd
-r--r--r--. 1 root root 2355408 Feb  9  2021 unifont.bin

Problem Point

Other

Affected Items

Other Loader

Debug Log

RefindPlus completely ignores it for some reasons. Other EFI loaders are found and shown:

   0:224    0:004  S E E K   U E F I   L O A D E R S
   0:226    0:002  Scan Internal:
                     - Found EFI\microsoft\memtest.efi on USB Partition
                     - Found EFI\microsoft\bootx64.efi on USB Partition
                     - Found EFI\rescuecd\memtest.efi on USB Partition
                     - Found EFI\rescuecd\bootx64.efi on USB Partition
                     - Found EFI\memtest86p\bootx64.efi on USB Partition

Additional Context

You can get it here:

https://www.memtest86.com/download.htm

This is reproducible on real HW and in a VirtualBox VM.

BTW, thanks a TON for the fork! Classic rEFInd doesn't show anything on my new laptop while RefindPlus works.

startergo commented 1 year ago

Have you tried loading it as tool?

birdie-github commented 1 year ago

Have you tried loading it as tool?

I'm not sure what you mean.

I'm not using any special options, the config file is untouched (default).

boot

startergo commented 1 year ago

rEFInd (and RefindPlus) gives special treatment to the EFI/tools subdirectory, where it looks for system tools rather than boot loaders.

# The default setting is shell, memtest, gdisk, apple_recovery, windows_recovery, mok_tool, about, hidden_tags, shutdown, reboot, firmware, fwupdate
#
# Setting "showtools" alone, with no options, completely disables scanning for tools.
# Scans for default tools when commented out
#
#showtools shell,bootorder,gdisk,memtest,mok_tool,apple_recovery,windows_recovery,about,hidden_tags,reboot,exit

In theory if you place the memtest in EFI/tools it should show up in the tools menu.

startergo commented 1 year ago

These are the expected memtest efi names:

define MEMTEST_NAMES L"memtest86.efi,memtest86_x64.efi,memtest86x64.efi,bootx64.efi"

https://github.com/dakanji/rEFInd/blob/d5c0a48a01427ed7a3cb3eb324c59fb965358b1d/refind/scan.c#L88

birdie-github commented 1 year ago

The question is an OS could be named anything, right?

There's a valid BOOTX64.efi - why is it being ignored?

"Classic" Refind sees it.

I mean isn't it crazy that memtest86p/bootx64.efi is detected and found and memtest/BOOTX64.efi is not? ;-)

dakanji commented 1 year ago

As @startergo pointed out, MemTest is a tool and if you want to use it, you should put it in an appropriate location and add the relevant flag to the showtools list.

Tools (second row items) are not supposed to show up as loaders (first row items). The reason why it shows up in rEFInd is simply down to a bug which has been largely, but not yet completely, eliminated in RefindPlus.

The last vestiges of this bug will be eradicated in the next release of RefindPlus. I already have the code on my local machine and it will be pushed at some point later.

I mean isn't it crazy that memtest86p/bootx64.efi is detected and found and memtest/BOOTX64.efi is not

Not really if you know how things work. To RefindPlus, the former is a file related to some unknown item called memtest86p that it therefore needs to show as a loader while the latter is a MemTest file that should only be shown in the second row (if the memtest flag is set).

EDIT memtest86p appears to be a version of memtest that is not currently recognised as such by RefindPlus. Will rectify this.

birdie-github commented 1 year ago

Here's what I think about all of that:

This all looks extremely dubious for me. Also:

There are seemingly 7 (seven) completely counter intuitive decisions in terms of dealing with specific arbitrary EFI applications.

You've given 0 (zero) reasons why this complexity should exist.

What I loved about Classic Refind is that it just works out of the box.

Now you ask me to learn

Sorry, this all looks like complete madness. What's even worse, there's nothing in the EFI standard ( https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf ) which even has the word "Tools" in it (aside from "EBC Tools" but that's not what you had in mind).

Nothing about tools here or here:

The "Tools" concept is extremely counter-intuitive, illogical and complicated for no reasons.

birdie-github commented 1 year ago

Oh, there's this:

UEFI Application
Modular code that may be loaded in the boot services environment to accomplish
platform specific tasks within that environment. Examples of possible applications
might include diagnostics or disaster recovery tools shipped with a platform that run
outside the OS environment. UEFI applications may be loaded in accordance with
policy implemented by the platform firmware to accomplish a specific task. Control is
then returned from the UEFI application to the platform firmware.
2.1.2 UEFI Applications
Applications written to this specification are loaded by the Boot Manager or by other UEFI applications.
To load a UEFI application the firmware allocates enough memory to hold the image, copies the sections
within the UEFI application image to the allocated memory, and applies the relocation fix-ups needed.
Once done, the allocated memory is set to be the proper type for code and data for the image. Control is
then transferred to the UEFI application’s entry point. When the application returns from its entry point,
or when it calls the Boot Service EFI_BOOT_SERVICES.Exit(), the UEFI application is unloaded from
memory and control is returned to the UEFI component that loaded the UEFI application.
When the Boot Manager loads a UEFI application, the image handle may be used to locate the “load
options” for the UEFI application. The load options are stored in nonvolatile storage and are associated
with the UEFI application being loaded and executed by the Boot Manager.

But again 0 indication that an "application" has to be put in a specific directory.

birdie-github commented 1 year ago

@dakanji @startergo

Please reply.

I hope that's going to be a thoughtful reasonable rational answer with solid arguments based in real life, common sense and logic, thank you very much.

birdie-github commented 1 year ago

Speaking of

#define MEMTEST_NAMES           L"memtest86.efi,memtest86_x64.efi,memtest86x64.efi,bootx64.efi"

Yeah, you indeed imply MemTest is a single EFI binary when it's not.

MemTest86 (not memtest86+) consists of a dozen files plus an extra directory and it requires a dedicated directory for itself to function.

You heavily imply all the tools are simple single file EFI loaders.

Seemingly over 200 lines of code for a completely arbitrary artificial decision.

I understand Refind has built-in tools, it's fine, let them be in a second separate row. But these are simply application functions, not tools.

I do not understand why you mandate that some other external separate EFI loaders must be tools as well. That makes 0 sense.

birdie-github commented 1 year ago

Speaking of arbitrary tools, you have not considered other tools:

Again what I'm trying to say is that simply enumerating /boot/efi/*/*x64.efi files is a whole lot easier than adding completely unneeded arbitrary chosen complexity.

dakanji commented 1 year ago

Please direct your observations upstream (the rEFInd project). Changes made there will be adopted here.

You ask the user to know/learn about what constitutes an OS and what constitutes an utility, with no clear indication/distinction between them

On this however, what constitutes a tool is clearly spelt out in the documentation and in the config file:

https://github.com/dakanji/RefindPlus/blob/7c56fb98c4e7dbe964f04831590efe98876840e8/config.conf-sample#L608-L647

rEFInd configuration guide (Works for RefindPlus) is here: https://www.rodsbooks.com/refind/configfile.html

birdie-github commented 1 year ago

Refind should have never had tools in the first place.

It has built-in EFI routines, e.g. "Boot into EFI configuration", Reboot, Power off - that's it.

There's no need to treat arbitrary EFI loaders as "Tools".

dakanji commented 1 year ago

this all looks like complete madness

I have always found it interesting that a person that makes such an inflammatory statement can, with the next breath, turn around and claim they are looking for a thoughtful reasonable rational answer

Anyway, deep breath....

Let's pick the points made one by one:

You ask the user to know/learn about what constitutes an OS and what constitutes an utility, with no clear indication/distinction between them.

  1. RefindPlus (which you wrongly call Refind Plus) does not ask a user to learn this, but the upstream rEFInd project (which you call Classic Refind) has done so.
  2. The rEFInd project has documented what these tools are.
  3. Tools in RefindPlus are the same as in rEFInd apart from one additional tool, CleanNvram, added to RefindPlus
  4. This addition is documented under Divergence in the readme on this repo's front page
  5. All significant differences to rEFInd in RefindPlus are documented in that section

You ask the user to put utilities files into "Tools" (no idea where this directory should be and how files need to be placed in it). Never used in Classic Refind either.

As above and the Never Used statement is false. You are clearly not as familiar with rEFInd as you think.

You ask the user to edit the configuration file in order for Tools to become visible.

RefindPlus does not ask such. It simply follows what rEFInd has established which is to show a default set of tools unless changed by a user.

Maybe I understood you wrong but it looks like Tools comprises of a single EFI loader when MemTest86 consists of a almost a dozen files and a directory

The rEFInd project has determined memtest to be a "tool" and this, as with 90% of stuff, is followed by RefindPlus. If you think it should be changed, ask upstream.

Here's another counter example: Fedora Linux has its MOK manager in this file: /boot/efi/EFI/fedora/mmx64.efi. Now you're saying specifically for Refind Plus I should move this file elsewhere? Does that mean files duplication for no reasons or breaking my Linux package consistency?

RefindPlus does nothing differently to rEFInd on this and does not have any RefindPlus specific requirements on this. Please refer your concerns upstream.

This all looks extremely dubious for me.

Ask upstream please

Tools are shown as small icons in the second row. Why? There are equally important.

The rEFInd project thinks differently. Same with the rEFIt project it was based on. If you want that the rEFInd project changes the structure it has been using for well over a decade now, I suppose you can always ask.

The EFI file is not shown for tools. Why?

Ask upstream please

You've given 0 (zero) reasons why this complexity should exist.

Ignoring that I do not see what the big deal is, the important thing is that you are barking up the wrong tree as RefindPlus did not exist when the structure was created by rEFIt ages ago, before adopted by rEFInd fork and now in the RefindPlus.

What I loved about Classic Refind is that it just works out of the box.

It doesn't seem you actually understand how tools work in rEFInd.

The only difference in RefindPlus regarding tools (apart from having an extra one) is that RefindPlus tries to consistently enforce the PRINCIPLE (established upstream) of tools only appearing in the second row.

In rEFInd, memtest will only appear in the second row under some circumstances and appear in both under other circumstances (random to a user). In RefindPlus, once the bug fix is completed, it will only appear in the second row under ALL circumstances unless given a non-standard name.

Now you ask me to learn XYZ list

There is nothing in RefindPlus that follows a different principle on the items in your list from what was established in rEFIt/rEFInd. Please educate yourself on those if you wish to make comparisons.

Sorry, this all looks like complete madness. What's even worse, there's nothing in the EFI standard

Keeping calm, please note this simple statement: REFINDPLUS DID NOT ESTABLISH THIS!!!.

The "Tools" concept is extremely counter-intuitive, illogical and complicated for no reasons.

The rEFit developer clearly felt otherwise about 20 years ago, the rEFInd developer obviously agreed and maintained this. RefindPlus has no intention of deviating from rEFInd on this aspect (as with most).

dakanji commented 1 year ago

Refind should have never had tools in the first place.

Please direct your views on the principles established by rEFit and adopted by rEFInd to the upstream project.

Thanks

birdie-github commented 1 year ago

Deal, I've already sent an email.

Sorry for the trouble and have a nice day!

Thank you for your answers anyways.

github-actions[bot] commented 1 year ago

This thread is being locked.

Please use the Discussions Feature for follow-on discussion or raise a new issue if appropriate.

dakanji commented 1 year ago

The EFI file is not shown for tools.

Buried within the rant, and consequently lost (as typical when communicating by ranting), was this apparent real issue. The MemTest Tool in RefindPlus did not pick up fallback loader files (bootx64.efi) and only explict memtest files (memtest_x64.efi, memtest.efi, memtet86.efi etc).

A HotFix build for v0.14.0.AA is planned to address a few issues that have cropped up post release. This feature will be included in that build; which will be added to the v0.14.0.AA release tag when completed. This is expected to happen sometime this week.