RefindPlus Hangs on HP Laptop

[Pigi-102]

RefindPlus Version

v0.14.1.AA Release

Device Type

UEFI PC

Problem Description

Hello all,
I have just got a new laptop ( ( HP Elitebook 655 G10 ) and as usual I've installed refing ( latest ), repartitioned my hard drive to shrink the windows partition, recreated all other partitions and extracted the dump for my linux installation.
At boot I got an empty refind screen without any choice available.
I've tried everything I've read around, removing unused drivers and son on, and also the Microsoft directory from the ESP thinkging it could lead to problems due to secureboot stuff, with no joy.
I've then tried to install an older version ( 0.13.3 ) which is actually working on my other PC, but also this show a white screen with only the refind logo.
Same happens when trying to boot from an USB "pen" with 0.13.3
I've the downloaded the 0.10.9 ( as find in older threads ) and burned on the USB pen, and with this I've been able to boot to linux ( until it crashed as maybe I'm missing some configuration in kernel ) with a panic unable to find root, but more impressively it boots in windows without problems at all.
I've been asked to test with refindplus, latest release, which I did and I have the same behavior.
So I've tried to use the DBG to get some logs and I'm attaching here.

Problem Point

Other

Affected Items

Other Item

Debug Log

24k19s3306.log

Additional Context

No response

[dakanji]

I see it hangs.

Can you try again and

1. Give it about 5 mins before stopping as runs from the ESP on USB sticks can be quite slow and perhaps it was just still on it's way
2. Remove potentially unneeded filesystem drivers and only load what you actually need
   • btrfs_x64.efi: Are you really running anything that needs this?
   • hfs_x64.efi: You don't seem to have Mac OS present
   • ext2_x64.efi: This should be covered by the ext4 driver
   • iso9660_x64.efi: No modern computer should need this
   • ntfs_x64.efi: You shouldn't need this if your unit supports Windows natively.
   • reiserfs_x64.efi: Are you really running anything that needs this?

Share a log after and we can take things forward.

Thanks

---

EDIT

Just noticed that your unit is an HP Elitebook.

HP firmware can be problematic ... especially on the Elitebooks.
Try the ransom_drives config setting

RefindPlus/config.conf-sample

Lines 435 to 450 in 18ad5f9

	# Some types of firmware, typically supplied by HP, may effectively lock partitions
	# as their "DiskIo" protocols are opened "BY_DRIVER", or a "partition driver", but
	# no filesystem is generated from the DiskIo. This stops other filesystem drivers
	# from connecting to the handles to actually generate filesystems when attempts
	# are made to install alternative drivers, making such partitions inaccessible
	# or hang in RefindPlus (as firmware supplied drivers may not be compatible).
	# When this token is active, RefindPlus disconnects such firmware supplied
	# drivers to accommodate otherwise disabled user supplied alternatives.
	# NB: This token is always disabled when Apple firmware is detected.
	# This functionality is only available on TianoCore builds.
	#
	# Inactive when commented out (Does not handle such partitions)
	#
	#ransom_drives

[Pigi-102]

I will try both things, as I only have ext4 and windows partitions, and more important I'll try the "ransom_drivers".
I only would like to remember that an old 0.10.9 rEFInd version works flawlessly so ( at least for refind ) this sound as a regression.

Thanks for your time !

[dakanji]

Caution

It is ransom_drives and not ransom_drivers

[Pigi-102]

Hello. Yes, it was a typo. I have simply removed the hash sign from the config file, just to be on the safe side.
I have tried both options as discussed ( remove the unused drivers and uncommented the option, and waited quite a long time on boot but still I only get the logo.
I'm attaching the new log.
24k20f3306.log

[dakanji]

That's bummer!

Before trying to look in more detail, please try again with disable_rescan_dxe also set along with ransom_drives.

Thanks

[Pigi-102]

Still no joy.
Log attached
24k20h3239.log

[dakanji]

I see.

Please try this build and share the log: https://temp-file-share.web.app/d/yk7M-uQ9q
Has no fixes and just activates very detailed logging to try to see where exactly it is falling over.

Note

This runs very much slower due to the logging level
Please give it about 2 or 3 mins

PS: Set log_level to 2

[Pigi-102]

There you go !
I left it running more than 5 minutes ( I will say lot more ).
24k20j0548.log

[dakanji]

Please try this one: https://temp-file-share.web.app/d/b8tl-0L7h

From the previous log, it does need more than 5 mins.

Thanks

[Pigi-102]

I will try also this, but it's hard to tell how long it should stay. I think last test I left it running for something like 10 minutes.
Should it be more ?

[dakanji]

That should be more than enough. Thanks

[Pigi-102]

Hello. This time I left it run 15 minutes.
On the screen there where two messages stating:

Error: Bad Buffer Size' While Scanning the '\' Directory on 'root1'
Error: Bad Buffer Size' While Scanning the '\' Directory on 'root2'

attached the log.
24k20q2001.log

[dakanji]

Thanks.

Please try this one: https://temp-file-share.web.app/d/VhVZ-sozC

On the Bad Buffer Size messages, did you actually get '' Directory or did you just leave the path out?

[Pigi-102]

No it's missing a backslash, probably due to formatting issue here on github.
I attach the photo.

[Pigi-102]

Now it's slightly better.
It shows the windows and all the tools but nothing about my two linux instances.
Should I add something in config ?
The old 0.10.9 shows quite a bunch of other options ( some due to the presence of several efi loader in ESP, but some due to the presence of a vmlinux in some of the partitions from disk).

Attached the log.

24k20r3104.log

[dakanji]

Quite a few things to get to grips with and need to look at the logs in some detail.
Please share your config file. You might need to zip it up as you might not be able to directly attach *.conf files

Thanks

[Pigi-102]

I've added the two entries I've in my refind.conf for my linux roots but they appears strange ( a yellow/black flag ) .
Not sure if they boot. I haven't tried, but I took the log.
Attached the config and the latest log ( with my two stanza added
24k20s3426.log
config.conf.gz
)

[dakanji]

Try going back to the original DBG file you downloaded and add the following config options:

1. "Windows RE Tools" to dont_scan_volumes ... The issue might be linked to that volume
2. ForgetMeNot to dont_scan_firmware ... This is a workaround for a different issue (NVRAM Boot Entries Are Shown As Shell Tools #184)

Thanks

[Pigi-102]

When you says "Try going back to the original DBG file you downloaded " you mean the 0.14.1.AA ?

[dakanji]

Yes

[Pigi-102]

Try going back to the original DBG file you downloaded and add the following config options:

1. "Windows RE Tools" to dont_scan_volumes ... The issue might be linked to that volume
2. ForgetMeNot to dont_scan_firmware ... This is a workaround for a different issue (All my firmware entries end up as shell tools #184)

You're right ! With those two settings, and the original DBG 0.14.1.AA it works. Attached the log from this last one.
24k21f4149.log

Why then the old 0.10.9 works ? It scan everything BTW. There are no configuration to not scan It simply ignore it ?

Thanks
You're welcome ! And thanks to you !

[dakanji]

Nice but are you sure it is working as expected? Your log file terminates abruptly.

Anyway, the second entry is unrelated to this item and the first one can be changed to just Tools.
You should be able to workaround the issue in rEFInd with this as well if you prefer using that.

I've added the two entries I've in my refind.conf for my linux roots but they appears strange ( a yellow/black flag ) .

This is because it cannot find the icon. You probably have a path that is invalid for your current temporary setup.

[Pigi-102]

Nice but are you sure it is working as expected? Your log file terminates abruptly.

Well, Kinda of. I'm also figthing with a regression on new kernel, so once I've seen the usual icons I had to poweroff the PC and start it by the old rEFInd just to continue with the same environment I'm using to test the regression.
( Basically this means that I'm doing the tests you ask between a compilation and reboot phase of my other problem )
But I'm confident that it will boot. I will give this a try later in the afternoon, when I will have some spare time and post the whole log.
If it works, booting from the usb pen, I will do some more tests with the not DBG refind plus and go on from there by using it on the ESP partition.
I'll let you know ( and will post result also on the rEFInd discussion, for others that may get the problem.

[dakanji]

Please confirm whether ransom_drives is needed here.
The HP firmware behaviour might be a relevant additional element.

[github-actions]

This item was addressed by Commit 00dcb08.

Current RefindPlus Release: v0.14.1.AA.
Refer to BUILDING.md to access functionality ahead of the next release.

Note

Alternatively, the issue can be worked around pending the next release by adding Tools to the dont_scan_volumes configuration token.

Thank you for taking the time to report a problem with RefindPlus.

[github-actions]

This thread is being locked.

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