RP BTRFS not working Oct 2024 through Apr 2026 - still NOGO

[MarioG-X]

FYI: While in the process of testing RefindPlus with systemd boot, I ran across the file on source forge referenced in issue #194 (which I can't update) and tried 14AD with the btrfs driver from source forge, NOGO. Only 141 with old btrfs drivers work. The upstream Refind 142 works fine as well with btrfs. Solutions: use Refind but Preboot volumes show up, or use RP prior to October 2024 works fine on everything. Will try systemd boot today but don't think will have much luck with macOS which is not an issue since I can use the Opt key to boot them.

Edit/Update 1:
Forgot to mention: No matter what btrfs driver I use none of them allows 142Ax to find btrfs partitions. First tested the 141 btrfs working driver with just changing the conf to 142 and leaving the working driver and 142AD fails, like all the other 142 versions. Since upstream works fine the issue is most likely with 142 RP, probably not the driver.

Edit/Update 2:
VERY surprised by this: I can boot RP to Opencore and OC finds both the EFI systemD AND newly installed Linux partitions and can boot BOTH fine. Interestingly OC does not find the linux partitions installed without systemD. So systemD using systemD has a big bonus with OC. You may want to look into how OC does this there is an opencorelinux drive but nothing for Btrfs. I will update this as I learn more after some tests. I am going to try 14AD again to see what it finds for systemD if anything.

Edit/Update 3:
Tried 14AD again (I tried it earlier before systemD and now after systemD) and although it found systemD and can boot it which can then load linux, it does not see the native linux partition that Opencore finds and boots as mentioned in update 2.

Good luck.

[dakanji]

Thanks for the feedback.

Will take some time to wrap my head around the train of thought laid out in due course.

EDIT
Items to remember

• Original Issue Linux Partitions Are Not Detected #194 suggests issue with BOTH Ext4 and BtrFS
  • This update appears to suggest issue is just with BtrFS (Silent on Ext4).
  • Do not run BtrFS, but could not replicate issue on Ext4 previously
  • Note some external reports of issues with Ext4:
    • [Ext4Dxe.efi] Can't boot to the new Ubuntu Linux in ext4 filesystem. acidanthera/bugtracker#2519
    • NB: Turned out to be spurious ... Not likely there is an issue with Ext4.
    • Interestingly, OpenCore now bundles Ext4 and BtrFS drivers from rEFInd 0.14.2 as "known working"
      • acidanthera/OcBinaryData@e74e533
      • Same BtrFS driver that is reported as not working and needing fixes on rEFInd forum
      • Likely a case of jumping the gun based on unreliable report
• This update suggests "rEFInd works fine with BtrFS"
  • Contradicts issues reported on rEFInd project: https://sf.net/p/refind/discussion/general/thread/172b9cbf09
  • Perhaps means after applying fixes to driver
  • Otherwise means BtrFS issues reported upstream are not universal
• This update suggests that RefindPlus stops working with BtrFS as from v0.14.2.AA
  • Inferred v0.14.2.AA from "October 2024" in title and the unclear shorthand version refs
• Not likely to get into this until well into 2026 if ever
  • Would need setting up a BtrFS instance purely to troubleshoot

[MarioG-X]

Additional info for when you work on this someday: I tested 142AD again for you to rule out EXT4, and it does find it (don't know why issue 142 seemed to have EXT4 problems). So I think you can rule out EXT4 related.

I ran a log of RP 142AD and and older RP 140AC just to see detected partitions and noticed that Linux volumes used to have their correct names shown, as (in this case TumbleweedB):
3:0261 0:0316 0FC63DAF-8483-4772-8E79-3D69D8477DE4 : 4A364F43-CB8B-46D2-9988-878FD087E8D4 : BtrFS : 00000000-0000-0000-0000-000000000000 : * Part Linux FS : TumbleweedB

In 142AD all BTRFS volumes show name as "Linux Volume":
2:9747 0:0276 0FC63DAF-8483-4772-8E79-3D69D8477DE4 : 4A364F43-CB8B-46D2-9988-878FD087E8D4 : BtrFS : 00000000-0000-0000-0000-000000000000 : * Part Linux FileSystem : Linux Volume

The EXT4 volume is the same on both logs (Gparted):
3:6874 0:0243 EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 : BC795741-97E5-4DDD-B19F-9663B79BBA6E : FAT-32 : 845B2044-0000-0000-0000-000000000000 : * Type Volume-BasicData : Gparted

I am using RP X330d-BOOTx64-REL.efi you provided during issue 142 testing, but without a debug version, so I can't get a log, otherwise I could do a more complete comparison. That shows the correct volume names so getting RP 142x BTRFS names correct is probably a good place to start. Hope this helps.

[dakanji]

Noted. Thanks

[MarioG-X]

dakanji, just an addition to my comments above that may help you. I worked all week on systemd boot and combining it with RefindPlus. I have concluded the following this week:

1. RefindPlus 142x is the only booter that no longer recognizes BTRFS volume names, so cannot find BTRFS kernels. I tested different 142x versions with many different levels of btrfs efi drivers and none work with RP 142x.

2. Upstream Refind finds and boots all BTRFS volume using the btrfs driver that comes with it. That driver does not help any 142x though.

3. Shockingly, OpenCore also has no issue finding and booting BTRFS volumes. Nice bonus.

I now have Refind Plus, upstream refind, and systemd boot on a Mac mini and iMac, also OpenCore on the iMac. All boot into RefindPlus first for now. I can now quickly boot between them, and into the upstream version to compare any issue to RP.

Please see my comments I added today: https://bugzilla.opensuse.org/show_bug.cgi?id=1226122#c77. It has a log of all cross booting tests I made. And a plug for RefindPlus, although I did not mention the temporary btrfs (I hope) issue #142.

[dakanji]

I took the time to install OpenSUSE Leap 15.6, taking care to ensure the partition is properly labelled as LEAP-1506 after ultimately finding the hidden option in the painful to use installer, which I gather has been changed to Agama. Anyway, RefindPlus 0.14.2.AD displayed the label and had no issue booting into the installed BtrFS instance.

Knowing there might be a question about the new 16.0 release, I had considered this but LEAP 16.0 has dropped support for my x86-64-v1 unit. Tumbleweed does apparently still support such but I cannot abide such setups. SlowRoll is apparently a saner implementation, but I saw in your bug report that the OpenSUSE devs have, as from 16.0, apparently decided one must select to have a bootloader installed or the installer will proceed to create an unbootable instance as they will not put things into standard locations to be found by RefindPlus or similar as was the case before or when using other installers. You can skip installing a bootloader on Debian or Ubuntu and everything works.

I saw there might be a workaround of selecting the option to install a bootloader and then telling the installer to not update the nvRAM but I do not want a bootloader installed as I already have one that does the job. It seems completely mad to decide to change things to now proceed with creating an unbootable instance in such cases. Decided it was too much hassle.

I digress. The takeaway is that Ext4 works as it should, BtrFS works as it should and labels are shown as they should.
You need to look into your setup if not happening for you.

[MarioG-X]

Greatly appreciate you taking time at this. Some feedback to your comments:

I use Tumbleweed, have for years. It does not use agama. I format partitions in the installers every time so they are fresh on a GUID disk. I am pretty sure Tumbleweed did not drop support for x86-64-v1 yet but all new development must be v2. I have not used OpenSuse for years, and never tried slow roll, etc.

The Tumbleweed installer is not agama, it's the original. It always had an option to not install a boot loader. And now has an option to install a boot loader and NOT modify NVRAM, in fact that was the whole purpose of the bugzilla link above I started in 2024 (so RP could stay in control). I always turn off options to change NVRAM and everything else in the installer boot option. That leaves RefindPlus in boot control. This is how I've been testing systemd boot, I installed about 20 times this last week with two machines with systemd boot, but the options left RefindPlus in boot control.

Labelling can be done in the installer, yes, hidden in FSTAB options. Just enter the volume name. Or change the label anytime after first boot with: sudo btrfs filesystem label <mountpoint_or_device> <newlabel>, I used that once when I forgot, changed "/" fine.

There does not seem to be anything wrong with my setup since older RP 141x (and 140x) work fine with old and new btrfs partitions. In fact, older 141x work with different versions of the btrfs driver. Also, as I mentioned above, upstream Refind (with its supplied btrfs driver), Systemd boot, and open core all find and boots every btrfs partition.

I appreciate the frustration with this issue, it's sounds like a tough issue to find. The only thing to please keep in mind as mentioned, 141 works with RP and upstream drivers, 142x does not work with any drivers, so I think the affected change was in 142x, not the driver, unless 142 is now tightly tied to drivers.

I know you did not plan to work on this at this time, but if you open issue #194 back up I will add anything new I find.

Do you want me to test the last btrfs driver you uploaded to sourceforge yesterday? I probably will anyway.

[dakanji]

Also, as I mentioned above, upstream Refind (with its supplied btrfs driver), Systemd boot, and open core all find and boots every btrfs partition.

The point I am making is that this is exactly what I get with RefindPlus v0.14.2.AD. The question then becomes, why for me and not for you?

To test things, replace the rEFInd efi file with the RefindPlus one (rename to match) and do not change anything else whatsoever in that setup.
If the problem is the RefindPlus file, then that setup will stop finding BtrFS. If it does not stop finding BtrFS, the issue is not the efi file.

The BtrFS driver thing is not related as the old version works for you and did for me.
Seems that is something that affects some specific setups as reported upstream.

Forgot to add my log file before: 25v23f2031.log

[MarioG-X]

I tried the sourceforge version. It totally does not work, looping on some Btrfs messages scrolling too fast to read. Thankfully, I had macOS Ventura to fall back on to fix things.

Here is the log of todays 14AD test using supplied 14AD Btrfs. I think missing volume names are probably an issue since they show up in 141x. 25v23u1426.log

I don't know if it makes a difference but this system, has 2 disks, each with an ESP. Refind boots from EFIS, then can boot other stuff in EFIH (systems, OC). Here is the layout: disklayout.txt

However, keep in mind this is an issue on the other computer where RP and all Linux's are on an external SSD, internal SSD only has 2 macOS systems. So location probably has nothing to do with it. I boot into RP on that one using Option key.

I tried to compare logs but not much for me to know about. I do not have SWAP since no need for it. Also, don't know what your EXT4 partition is. Mine has all Btrfs partition names missing which I think may have something to do with it. Looks like GUID types, etc. are correct.

Going to test Refind with RefindPlus efi now. Be right back. That's one I did not try.

[dakanji]

As mentioned, the driver item is not relevant to you:

The BtrFS driver thing is not related as the old version works for you and did for me.
Seems that is something that affects some specific setups as reported upstream.

What you need to do is this written before:

To test things, replace the rEFInd efi file with the RefindPlus one (rename to match) and do not change anything else whatsoever in that setup.
If the problem is the RefindPlus file, then that setup will stop finding BtrFS. If it does not stop finding BtrFS, the issue is not the efi file.

[MarioG-X]

The results are: the current upstream Refind does NOT work with the Btrfs driver supplied with RP 14AD. The testing steps:

Replace the RefindPlus EFI with the one from upstream Refind.
Copy the Btrfs EFI from RP 14AD to drivers x86.
Rename the 14AD Btrfs driver to match the name supplied by upstream brtrfs efi name.
Boot, it did NOT find any BTRFS volume.

I then replaced the Btrfs driver with the original one from upstream and rebooted and Refind then displayed all Btrfs systems and could boot into them.

So it seems something is quite different between the drivers, also I noticed the RP driver is about twice the size of upstream Btrfs driver. So they do not work with each others drivers at this time, which is why it's possible there is an issue with the driver and RP?

[dakanji]

• You said you have a rEFInd setup that works with BtrFS
• I said to swap in the RefindPlus efi file into that setup (rename RefindPlus efi to match the rEFInd efi that was originally there) without changing anything else whatsoever.

You are doing something else altogether

[MarioG-X]

I mentioned above that I had already done that. I tested many combinations this week except for the one I just did.

[dakanji]

I mentioned above that I had already done that. I tested many combinations this week except for the one I just did.

I don't believe you have and perhaps you didn't fully get what was requested.

To spell it out step by step:

• Assuming you have a rEFind efi named Refind_x64.efi in the working instance, rename that to Refind_x64.efix.
  • That is, change the extension from efi to efix to disable this file
• Copy the RefindPlus efi file into that setup and rename this as Refind_x64.efi
• Do not change anything else whatsoever

Run this as you normally run the rEFInd instance

[MarioG-X]

I do exactly that all the time. Yes I renamed old versions. Been doing that for years. I don't see anything different from what I did.

I swapped the RP Refind_x64.efi and x64_ext4.efi files with the ones from Refind (btrfs_x64.efi). And Refind finds BTRFS volumes on both systems. Refind has never had an issue finding Btrfs volumes. Nothing else was changed.

[dakanji]

Sorry, but we are going around in circles here.
Your response about changing BtrFs etc suggests you haven't done what was asked.

There is a Refind_x64.efi file. Disable this and replace with the x64_PrefindPlus_XYZ file renamed as Refind_x64.efi.
Do not change anything else. Not the ext4 driver or BtrFS driver or config file or anything else. Nothing else whatsoever should be changed.

This is not what was done

[MarioG-X]

Forgot: yes I have multiple work arounds and was going to leave it there. I did all this testing and new layout of boot directories for your benefit thinking you might like to fix btrfs in the future for the next person and I was glad to help. My work here was NOT for my benefit.

[dakanji]

Thanks. Appreciated.

[MarioG-X]

I have more info. I know you want to drop this since I don’t need a fix but I am as curious as you and want to help, but I don't know if this will help:

You mentioned needing a “basic system” so I built one. I have a Mac Mini that ONLY has 2 macOS APFS systems internally and NOTHING in its ESP except APPLE. Nothing on the Mini was changed. I formatted an external USB stick with an ESP partition and one BTRFS partition with no sub volumes. I created a boot directory containing rEFInd on the new external ESP, and freshly installed Tumbleweed with NO boot loader to the btrfs partition. You will see it in the log files below.

I ran many test combinations doing renames only, note the RP tests only have the btrfs driver in the drivers directory.

## Booter		Driver		Result
 1 rEFInd		rEFind		Good
 2 RP 142AD   	rEFInd		Bad
 3 RP 142AD	    RP 142AD	Bad
 4 RP 142AD	    2024		Bad	    driver Oct 8, 2024, interesting driver works with 330 b3-E.
 5 x330C		RP 142AD	Bad
 6 x330D		RP 142AD	Bad

 7 x330E		2024		Good	Oct 14/14, 2024, driver from Oct 8, 2024
 8 x330D		2024		Good	Oct 12/13, 2024, driver from Oct 8, 2024
 9 x330C		2024		Good	Oct 12/13, 2024, driver from Oct 8, 2024
10 x330b3		2024		Good	Oct 12/12, 2024, driver from Oct 8, 2024
11 x330b2		2024		Bad	    Oct 12/12, 2024, driver from Oct 8, 2024
12 x330b		2024		Good	Oct 12/12, 2024, driver from Oct 8, 2024

As you can see for the 330 series I went backwards until b2 which did not work, however going back to 330b worked. B3 through E which were the last ones supplied by you worked. There were 5 more before b, their results can be found in issue #194.

This is as BASIC as I can make a system here without erasing the internal disk which I can’t do.

Here is the log to the working rEFInd: refind.log

Here is a log for a non-working RP 142AD: RPD25v27w2651.log

There was no debug version of the 330 series. If you want something else to test I will be happy to do so.

[dakanji]

Thanks. Insightful.

Note though, for the record, that I didn't ask you to change your system or create any kind of system, basic or otherwise.
What I asked for was to change one efi file, and one efi file only, and specifically asked not to change anything else whatsoever.

FIRST: #242 (comment)

To test things, replace the rEFInd efi file with the RefindPlus one (rename to match) and do not change anything else whatsoever in that setup.

NEXT: #242 (comment)

What you need to do is this written before:

To test things, replace the rEFInd efi file with the RefindPlus one (rename to match) and do not change anything else whatsoever in that setup.

NEXT: #242 (comment)

• You said you have a rEFInd setup that works with BtrFS
• I said to swap in the RefindPlus efi file into that setup (rename RefindPlus efi to match the rEFInd efi that was originally there) without changing anything else whatsoever.

NEXT: #242 (comment)

To spell it out step by step:

• Assuming you have a rEFind efi named Refind_x64.efi in the working instance, rename that to Refind_x64.efix.
  • That is, change the extension from efi to efix to disable this file
• Copy the RefindPlus efi file into that setup and rename this as Refind_x64.efi
• Do not change anything else whatsoever

NEXT: #242 (comment)

• There is a Refind_x64.efi file. Disable this and replace with the x64_PrefindPlus_XYZ file renamed as Refind_x64.efi.
• Do not change anything else. Not the ext4 driver or BtrFS driver or config file or anything else. Nothing else whatsoever should be changed.

LAST: #242 (comment)

To recap:

• Rename the X330d-BOOTx64-REL.efi file as X330d-BOOTx64-REL.efix to disable the file
• Copy the RefindPlus 0.14.2.AD efi file into that setup and rename this as X330d-BOOTx64-REL.efi
• Do not change anything else whatsoever
  • No BtrFS driver changes, no config file changes, no changes at all
  • Only difference between previous working setup and new should be that the main efi file was changed.

I presume the conditions requested were ultimately hit but there will always be a small question mark given the circumstances.

Anyway, there is not much to be gained by doing anything further on your side at this time.
So, please do not do any further tests on this for now.

Thanks again. I believe there is a holiday where you are. Enjoy it.

[MarioG-X]

No problem, I know you didn't ask, and I will not do any more tests unless you ask. It was my time and setup only took an hour, mostly waiting for Tumbleweed install, then testing an hour. Documenting took longer!

Now that I have a simple "basic" system containing minimum ESP files and fewer operating systems, RefindPlus issues like this one may be easier for you. Your system is far more complex with Windows, etc.

FOLLOW UP TO PREVIOUS TEST ABOVE:
Right after I sent the status chart above, out of curiosity I then tested 330b, I added it as step 12 above, and it worked! Prior to 330b all or most tests failed, I don't have a record and did not retest them.
To summarize your changes (all using the Oct 8 2024 btrfs driver):

• 330b worked,
• then 330b2 failed
• then 330b3 through 330E worked
• then broke again in 142AA
  I retested them using the 142Ax driver, none worked for btrfs. This seems there may be two separate btrfs issues, one you found in 330b2 and fixed in b and b3-E booters, but then something introduced in the 142Ax btrfs driver prevented it from working with all version of RPs.

CLARIFICATION OF TEST 1 and 2
It may not have been clear/obvious to you due to us using different naming conventions, so detailed steps should clarify. Everything you asked had been done with the same results as the other machine with multiple booters and OS's. Note I am using the option key to boot the Mac Mini into RefindPlus and rEFInd from an external drive. Using the Option key to boot requires that the file name must be BOOTX64.EFI located in /boot (case does not matter):

• You said you have a rEFInd setup that works with BtrFS

The is item 1 above. New/empty ESP:

• Copied rEFInd files to /boot I. Nothing but original rEFInd files and directories, just rEFInd btrfs and ext4 in drivers directory.
• Renamed refind_x64.efi to BOOTX64.EFI
• Edited refind.conf to add "log_level 4" (real slow!), see log above.
• Boots macOS's and Tumbleweed btrfs fine. Same as succesful tests on other machine.

• I said to swap in the RefindPlus efi file into that setup (rename RefindPlus efi to match the rEFInd efi that was originally there) without changing anything else whatsoever.

That is exactly #2 above, right after the rEFInd test above:

1. This was your request to "What I asked for was to change one efi file, and one efi file only":
   1a. Renamed rEFInd BOOTX64.EFI to BOOTX64.EFIrf
   1b. Copied 142AD x64_RefindPlus_REL.efi to /boot
   1c. Renamed x64_RefindPlus_REL.efi to BOOTX64.EFI. NOTHING ELSE WAS CHANGED. rEFInd btrfs and ext4 drivers only.
   Booted and received an error message from RefindPlus that config.conf was missing, and did not get a log. Finds macOS's but no Tumbleweed btrfs.
2. I did it a second time with debug, added config.conf, removed ext4, it made no difference:
   2a. Copied 142AD x64_RefindPlus_DBG.efi
   2b. Deleted BOOTX64.EFI
   2c. Renamed x64_RefindPlus_DBG.efi to BOOTX64.EFI
   I made 2 other changes this time: removed ext4 since there is no ext4 partition. ext4 made no difference. And I added config.conf with symlink ON. For both of these tests, the original rEFInd btrfs driver was left in place. Same results, finds macOS's but no Tumbleweed btrfs.

If you want any steps clarified or need a test anytime sooner or later feel free to let me know. I will be glad to help.

[MarioG-X]

FYI to interested parties. 142AE does NOT fix this issue for me. Linux Tumbleweed btrfs volumes on multiple computers, internal, external are not able to boot even though the volumes are found by RefindPlus. Volumes names are missing same as before (see log). Going back to 2024 is fine. Boots fine from Opencore and SystemD, same as before.

In case someone assumes I must be doing something wrong, I have been testing RefindPlus, providing debug logs and testing scenarios for years. I designed and written a commercial telecommunication system in assembly language, worked on million+ line systems, was guest speaker, etc. Testing/renaming/moving in a dozen file directory is easy to get right.
26h15u1049.log.zip

[dakanji]

Well, nothing was done on this item in 0.14.2.AE and the expected outcome therefore, with everything else the same, would be as it was before.

I am not positioned to install Tumbleweed but able to load Leap 15.06 ( See log: - 26h16e4153.log ).

I suppose you could try Leap 15.06 to see what happens.

[MarioG-X]

An observation that I previously reported shows same in your log. In case it's a clue add to knowledgebase:

The line in your log for the btrfs volume is identical to mine that works using x330d (which is what I have been using since 2024. Every test that I ran using x330d looks like yours with the correct volume name:
2:2828 0:0107 0FC63DAF-8483-4772-8E79-3D69D8477DE4 : E12792AA-72BE-4B6A-9B8F-960547AD94BC : BtrFS : 00000000-0000-0000-0000-000000000000 : * Part Linux FileSystem : Leap_1506

Every test here, on in internal, external, SSD, HD, and even a fresh built USB stick with fresh installed OS using newer than x330d looks like this, which displays "Linux Volume" instead of the actual volume name. GUIDS, etc. look fine:
2:1047 0:0156 0FC63DAF-8483-4772-8E79-3D69D8477DE4 : 6DACEDBD-B325-4D1C-85CB-FE4C3A8ADE6B : BtrFS : 00000000-0000-0000-0000-000000000000 : * Part Linux FileSystem : Linux Volume

Since x330d works and Opensuse uses same GUID and volume/directory layout should eb the same. Anyway, I know you're not working on fixing this so will keep x330d which is perfect.

[MarioG-X]

FYI: Even though x330d, Refind, etc work for me, my curiousity got the best of me and I (tried) to install Opensuse 16.0. Two+ hours to figure out why the install ISO gets stuck in boot (video problem), then the next day 2+ hours trying everything to allow me to use existing partitions (nogo). So no Opensuse test. Opensuse 16 installer ISO boot and Agama stinks/unusable. Staying on Tumbleweed until they shove Agama down our throat in Tumbleweed.

[dakanji]

The misc x files are created for a specific test and discarded after.
References to such are of no bearing to anything on my side and continued use after the test they were constructed for is ill advised.

As for tests, the only relevant one right now is the ignored suggestion to check Leap 15.06.
This would have checked whether an instance that was shown to work on my unit also does on yours.
A check of 16.0 is of limited use in moving the needle as if it also fails, nothing new would have been revealed.

[MarioG-X]

Yes I considered trying 15 but after reading many people had the same issue not being able to get past Agama storage options I decided not to waste time since Opensuse 15 and 16 use the same Agama. x330d may be ill advised but boots everything perfectly. No choice here if I want to use RefindPlus. Hopefully the issue may reveal itself someday. Thanks for the response.

[MarioG-X]

Curiosity got the best of me, I was able to install Opensuse 15.6 and it was bootable on x330d, RefindPlus prior to AC, Refind, SystemD, Opencore. But AE same problem, 15.6 not found and log file shows generic volume name as previously mentioned. I do not expect you to work on this, just a bit of info to add to the issue.

By the way, recently, a NEW problem, it appears the latest Tumbleweed, and other distros are removing the Linux kernel from /boot since it is a duplicate of /boot/efi (the EFI partition) so RefindPlus, and probably others, don't see the kernel. For now, the workaround is to boot RefindPlus then select SystemD, and boot Linux from there. An issue for another day. This must be progress?

[dakanji]

So, confirmed that it isn't that BtrFS is not working across the board but that for some reason, it isn't on your unit.

On the partition name not showing, are you sure you labelled it? What does blkid show?

As for whatever moving kernels to wherever, RefindPlus and rEFInd have default places they check, but what's stopping you from adding locations you need to the your config file ... to also_scan_dirs for instance?

[MarioG-X]

Oh, I expected that. Why would you ask that when the volumes names correctly show up in logs for RefindPlus that work? Linux volumes names are correct in blkid, and even macOS. ONLY RefindPlus 142AC, AD and AE not working, all previous RefindPlus and current upstream Refind finds volumes names correctly and boots the kernel.

I am in the process of changing RefindPlus to only boot SystemD for Linux systems, and Opencore to boot non-compatible macOS. For compatible macOS system I just use the Option key. I still use RefindPlus to boot a USB system installer.

So at this point I gave up trying to get newer RefindPlus to boot Linux. Not a big deal. I just thought you might like to know about issues and I was willing to work on them for you. Anyone else new to RefindPlus who has this problem will just skip it. And when you add the new problem I mentioned above (I just installed todays Tumbleweed and /boot is empty now), have to use SystemD now anyway. This problem is obviously too hard to fix so time to move on and circumvent.

[dakanji]

At the end of the day, it works for me and I can't fix what doesn't manifest on my unit. There's obviously something different between our units unless you can, given your enormous experience, can postulate why the difference.

If someone has the issue and is able to investigate find what is happening and fix or at least locate a breaking commit, then can take forward.

In your case, probably best use one of the other alternatives that work for you unless you can offer something proactive.