Does not work on my HP notebook

[btwise]

RefindPlus Version

v0.13.2.AN Release

Device Type

UEFI PC

Problem Description

Why on my computer, the main menu and system entries cannot be loaded normally with this version, it only stay on the logo of RefindPlus,but the Clover works fine, refind 0.10.x also works fine, refind 0.12 and above is the same problem as your refindplus

Problem Point

While starting a loader or tool

Affected Items

All OS Loaders (First Row Items)

Debug Log

22d23i0759.log

Additional Context

No response

[dakanji]

Can you try the alternative build and report on the outcome? Link: https://github.com/dakanji/RefindPlus/releases/tag/v0.13.2.AN

[dakanji]

Other query is why have you just blindly added all the extra binaries provided without consideration of whether you actually need them or whether they are actually drivers to start with?

The three shown above are not even drivers and are binaries that serve specific functions. I always struggle to understand this approach of just blindly loading any/every thing found.

[btwise]

I think it has nothing to do with these EFI tools. I can remove these tools or driver files and get the debug file again, but I cannot refresh it to the startup menu. What is the problem

I also tried to compile the latest source code myself, and the same thing happened

[dakanji]

Well, whether it is related to them or not, the point is that you should not just load things just like that and as I said, three of the items loaded as drivers are not even drivers. Seems you just saw a folder full of binaries and simply decided to load them all without regard to what they are or what they do.

I also tried to compile the latest source code myself, and the same thing happened

Share the log from your run of the build or from the alternative build I linked to

[btwise]

22d23p4534.log This is the debug log you get with the v0.13.2.AN you specified, it stops after showing the banner，I don't have any external drivers and tools loaded

[dakanji]

OK. So you said you have a similar issue with rEFInd and that this started with v0.12.0? Can you share a log from the current rEFInd version ... v0.13.2? You can download here: https://sourceforge.net/projects/refind/files/0.13.2/

Set the log_level to 4.

Thanks

[btwise]

@dakanji refind.log This is the log obtained using rEFInd 0.13.2!

[btwise]

What's the reason?

[dakanji]

What's the reason?

RefindPlus is derived from rEFInd

[btwise]

I know ! it's the same problem now, there must be some positions that rEFInd hasn't actively addressed, hope you can solve it

[btwise]

The lower version of rEFInd does not appear to have logginqg capabilities and cannot be compared

[dakanji]

This is the debug log you get with the v0.13.2.AN you specified

I just checked and you didn't use the Alternative Build I asked for.

There two packages on that release item. I wanted you to try the Alt-RefindPlus_x64-001302_AN.zip package.

[btwise]

Okay, that's easy. What does the ALT prefix mean?

[dakanji]

What does the ALT prefix mean?

Should be obvious ... ALT = Alternative There are notes on the release.

[btwise]

alt_Refindplus.log This is the Alt version of the log you requested, and nothing seems to have changed！

[dakanji]

No change indeed.

So far, it seems to be crashing when trying to scan your Mac OS disk. What happens if you disconnect that particular disk and only leave Windows?

[btwise]

I have used scanfor to remove the rule for scanning the internal disk in the configuration file. Why does it scan the internal disk partition? My internal hard disk has two hard disks: MACOS partition and WINDOWS partition. Removing it requires tools to disassemble my laptop. But why do refind 0.10.x and Clover both work, and you should be able to find the difference?

[dakanji]

Since I don't have your machine with me, the only way I can find out what is happening is to ask you questions and ask you to do things. Both rEFInd and RefindPlus crash when scanning your MacOS disk. The obvious test is to disconnect it to see whether they have an issue with it.

As for scanfor, if you have disabled scanning internal disks as you say, what exactly are you trying to boot then?

Please share your config file (as well as any theme or similar config files that you may be additionally loading via include)

EDIT: Actually, the issue might be the WIndows disk and maybe this is the one to disconnect first

[btwise]

I just want to scan my USB disk to start my WINPE and LINUX, just now it seems that the configuration file refine.conf and config.conf exist at the same time, it preferentially uses config, now I get the logs again, and only scan the external disk and manually configure entries

[btwise]

22d23r1939.log config.conf.zip This is the new log and configuration file obtained, the configuration file is just a simple modification, and there is no complicated content！ This time the log content is not the same as before, and the built-in disk is not scanned. It seems to be related to icon loading?

[dakanji]

I'll check the config file and scanfor angle later.

In terms of the issue, both rEFInd and RefindPlus are actually hanging at the same point, which is when or after scanning a Usm_PE volume.

You need to look at that volume to start with. Check what you have there and whether things work if you add it to a don't scan list or if you disconnect it etc.

[btwise]

Usm_pe is just a normal NTFS partition on an external disk, I can try to remove it!

[btwise]

I added dont_scan_volumes "Usm_PE"to the configuration file and it booted normally, but the scan speed seemed to be a bit long, more than 10 seconds, and there were no special EFI files or other contents for the Usm_PE partition.

[dakanji]

Well, obviously something with the volume they do not like. 10 sec is not a big amount of time.

You could reconnect the volume and try using the NTFS driver from the RefindPlus package. Not sure how the laptop is able to scan the volume without that being loaded to start with. Except perhaps the firmware loads this?

[btwise]

I load NTSF driver, connect to the volume, still cannot boot, can only disable the NTFS volume

[dakanji]

Ok ... did a search and there are a lot of issues with HP and what seems to be a buggy NTFS driver that they come with. An example is: https://sourceforge.net/p/refind/discussion/general/thread/f1f144d655/?limit=25#8c84/2e7a

You might need to go back to HP and make sure the firmware is up-to-date as there might have been a fix. Whatever the case, the primary issue is with the computer regardless of the fact that some other tools are able to work with it. Otherwise, you have to just disable the volume.

See the link posted for more insight.

[btwise]

Ok, thank you. My laptop is an HP 840 G3 on Skylake platform. Maybe there is no updated firmware

[dakanji]

I use the term firmware because of Mac background but I take it you understand I mean BIOS. No harm is taking a look to see.

[btwise]

yes,i see,I'm also a Hackintosher, and I use OpenCore too

[dakanji]

Before dismissing this, can you reconfirm that you are able to boot with the drive attached when using some old 10.x version of rEFInd?

EDIT I see this in your first post. Will keep this open and take a closer look later

[btwise]

Yes, the last version tested was 0.10.7, and it worked well with NTFS volumes constantly open, so I wonder if you can fix it in the 0.13.2 source code

[dakanji]

Hello,

Please try the attached X215 file and share a log: X215-BOOTx64.zip

You need to:

• Remove the dont_scan item
• Ensure the affected volume is present
• Add an NTFS driver

[btwise]

okay! 22d25m1846.log The problem still exists!

[dakanji]

Add an EXT4 driver and try again

[btwise]

The ext4 driver is added, the problem still exists, but if I use scanfor manual parameter is used, it is equivalent to disabling the scan function and it can work normally！ 22d26c1825.log

[dakanji]

OK. Please try X216: X216-BOOTx64.zip

This may work without anything special done.

[btwise]

no changes!still exists! 22d26j0034.log

[dakanji]

Thanks - That doesn't look like it came from the X216 file. Either you ran an old file or maybe I got mixed up when building.

Anyway, please rerun with X218, which has been verified as being mix up free on this end X218-BOOTx64.zip

You might want to remove earlier logs from the ESP before running it as the newest log file is sometimes not the last one. This can happen because of issues with the machine's timer.

[btwise]

I'm sure I'm not mistaken, the log file is this, the problem still exists！ x128.log config.conf.zip

[dakanji]

Thanks. This is definitely the expected file. Well, I don't have an answer to the issue at this point and you will have to work around it.

PS: Raise it upstream to the rEFInd project and mention that older versions work

[dakanji]

There is one last possible crazy thing you could try. Rerun X218 and load all the filesystem drivers in the RefindPlus package as you previously did. Just exclude the three (3) that are not drivers.

[btwise]

To no avail, I want to add judgment in the code, if the scan time exceeds the set value, stop the automatic scan, and use manual configuration

[dakanji]

For your background info, this issue with odd firmware behaviour, especially with HP Notebooks, appears to have been understood for quite a while and a stab at a fix was included in rEFIt in the early 2000's.

rEFIt gave birth to Clover and rEFInd before later dying off. Clover took and improved the rEFIt fix at some point. In v0.10.3 (2016), rEFInd incorporated the Clover fix with modifications. This fix is still there and exists in RefindPlus.

However, I noticed that Clover updated the fix in 2020 for unknown reasons, possibly because it had stopped working. I assume it would not have needed an update if it was working. The updated Clover fix appears to have been derived from OpenCore, which created a comprehensive fix for this issue in 2020. The Clover fix is very similar and appeared shortly after the OpenCore fix.

You have run tests with the updated Clover fix as well as the OpenCore fix incorporated in RefindPlus and reported that neither of them work. This is despite that RefindPlus hooks directly into the OpenCore functions. Perhaps i am missing something in the pipeline.

Anyway, X219 targets something that might have affected the outcome so let's see how that does.

[btwise]

Unfortunately, there was a serious problem with the x219 version test. I tested it twice and got the same result. Not only did it fail to boot, but it also caused the computer to fail to boot after a cold boot. Only by unplugging my external USB hard drive can it boot normally. , got an incomplete log!

I believe some fixes from clover were incorporated in refind 0.10.x, but since 0.11, is there some newly added code that breaks some of the previous fixes? The same happens with refindplus, since it is also derived from refind! x219.log

[dakanji]

Yeah ... Sorry. I noticed the issue and was just about to replace the file when I saw your message. Try X220 instead: X220-BOOTx64.zip

[btwise]

Yeah ... Sorry. I noticed the issue and was just about to replace the file when I saw your message. Try X220 instead: X220-BOOTx64.zip

ok,please wait while!

[btwise]

same result, same log！ x220.log

[dakanji]

Ok. Putting on ice for now. Thanks for helping with the tests.

Please report this upstream in the interim

[github-actions[bot]]

This item is being closed as a known issue.

[dakanji]

NTS: This should have been fixed by the RansomDrives feature but apparently not it seems. Remove 'Resolved' Tag