RP BTRFS has not worked since Oct 2024 - update

[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]

Results of booting into 142AD from systemd boot:

Btrfs works: Boot to RP X330d-BOOTx64-REL.efi then to systemd boot then to 142AD, sees Btrfs.
Fails: Boot to systemd boot then to 142AD, does NOT see Btrfs volumes.

So it seems as long as I first boot to x330 then directly to 142AD, 142AD displays Btrfs systems. Very strange.

[MarioG-X]

At least I have work arounds for now. I am sticking with RefindPlus since it's the best loader as I mentioned in bugzilla. If you're interested a tree of my EFI: EFItree.txt

Some good news for you about RefindPlus after converting to BLS:
You probably are aware of this but Tumbleweed, Opensuse and most other distributions are now following Boot Load Specification standards for where boot files go: https://uapi-group.org/specifications/specs/boot_loader_specification/ This is my reason for implementing systemd boot.

That is what I spent the week doing, changing about 10 partitions/systems over. After battling the first one since this was all new to me. The others went very smoothly. The good news for you: Even after the changes RP worked perfectly with no changes required. The boot screen showed as it always did. And as you read in (https://bugzilla.opensuse.org/show_bug.cgi?id=1226122#c77) RP integrated perfectly. If only this darn Btrfs problem would go away I could delete the dozens of RefindPlus test files I accumulated.

Thank you very much for the effort and time. Will pickup if/when you have something to try. I am out of ideas.

[dakanji]

Nothing to add I'm afraid. Apart perhaps from that the original issue will be flagged as Invalid given that from what can be seen so far, Ext4 works, BtrFS works and labels are shown on a properly configured setup.

Only possible thing you can do is to run the test I outlined earlier exactly as outlined without any changes assumed to be equivalent, even if you still believe you previously did this. The only difference in light of your last few posts perhaps would be to use the X330d-BOOTx64-REL.efi instance instead of the rEFInd one.

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.

Run this as you normally run the X330d instance
You can use the DBG version of RefindPlus 0.14.2.AD, renamed as X330d-BOOTx64-REL.efi as spelt out above to get a log file.

[MarioG-X]

This is very long, so please check the bottom for the word EDIT in case I find an issue or need to clarify something later.

Here goes, there is a lot of info below. I hope I remember everything. Here is your test request followed by another of mine where I booted from rEFind into 142AD.

But first, I ran your request (replacing your names since they don't match) for the I don't know how many times now. I may sound frustrated to the same request I ran many times. But I get it. I have been in computers for 50 years (started on IBM mainframes in the 70s). I got to the point where I was a guest speaker for many companies. And I had to help many people. Sometimes, I would run across a problem that sounds like this one and thought "there is no way... he/she MUST be doing something wrong". Sometimes it was their fault and sometimes it was really happening, but either way I had to make SURE we were on the same page before proceeding. So I get it.

Next, due to all the renaming and moving around, I decided to reorganize the EFI refind directories one or two days ago. Since I have the systems setup to easily boot between rEFind, RefindPlus. Systemd boot, and OpenCore, I thought, why not separate the different levels/versions of refind?

I created three directories for refind in EFI, each containing ONLY what it needs, I removed files I knew each did not use. This results in far less need to do renames and errors are much less likely. Turns out it's way easier for me but not it did NOT change any 142AD results. Here is the EFI, all I have to do is rename the directory to "refind" since that is what is targeted from NVRAM. Mostly, no need to rename Refind_x64 as often. So here goes:

Refind x330:

RefindPlus 142AD:

rEFind 0.14.2 (I call original):

So that is my EFI for refind from now on on all EFIs. MUCH easier to manage and test. I can add more if needed. And they can be booted very easily as the initial booter by simply renaming the directory, and can be booted from each other (see below).

Now for your test:

1. The refind330 directory contains config (edited for symlink), ext4 and Btrfs drivers from RefindPlus dated October 8 2024, also icons/keys from rEFind.

2. I renamed the refind330 directory to refind.

3. I renamed refind/Refind_x64.efi to refind/Refind_x64.efi330

4. I copied x64_RefindPlus_DBG.efi from the 142AD downloaded folder to /refind.

5. I renamed /refind/x64_RefindPlus_DBG.efi to /refind/Refind_x64.efi
   Here is end result of EFI/refind:

6. I rebooted.
   Here is the log you requested (missing all Btrfs systems): 25v24s4610.log

Now for something interesting, remember that 142AD finds Btrfs if first booted into x330? Well, is also works if I first directly boot to rEFind! Yes, as you know, rEFind finds Btrfs no problem, so I thought if getting into 142AD from x330 works, let's see if going from rEFind works, and it does! Here is the log of working 142AD booted from rEFind, similar to previous log of systemd boot going to 142AD: 25v24s5326.log and the EFI I booted from:

BtrFS works and labels are shown on a properly configured setup

BTW, what do you find improper about my setup? disklayout.txt
Note the system NVRAM boots to EFIS (internal SSD), the EFIH (internal HD) partition is only booted from EFIS booters. Everything we are testing is ONLY in EFIS. EFIH is basically a standby/backup.

[dakanji]

Thanks, but what you have done is not what I requested. Anyway, it seems there is not much to gain on this path.

You can proceed as works best for you, such as the workaround you mentioned or some other options.

[MarioG-X]

I did exactly as you requested just using a different name for the boot file. If I use X330d-BOOTx64-REL.efi the system will NOT find it and will not boot into it. The reFInd installation sets up NVRAM to point to Refind_x86.efi. Yes, I have work arounds, all pre 142Ax RefindPlus's work as well as rEFind, OC and systemd now all can boot into btrfs fine. I will take a crack at future RefindPlus's and keep you up-to-date since this seems too hard to fix for now.

[dakanji]

If I use X330d-BOOTx64-REL.efi the system will NOT find it

You said you were booting into this and then into 0.14.2.AD. Request was to change the efi and boot X300 exactly as you were doing before.

Anyway, best to move along. Thanks for the feedback.

[MarioG-X]

I think you are misunderstanding above or it is not clear. It is exactly what you requested. How is this (from above) different from your request. If I am off tell me the exact step below that does not match what you want (aside from naming conventions)
Now for your test:

The refind330 directory contains config (edited for symlink), ext4 and Btrfs drivers from RefindPlus dated October 8 2024, also icons/keys from rEFind. NOTHING is changed here.

I renamed the refind330 directory to refind. refind dir is now working 330.

I renamed refind/Refind_x64.efi to refind/Refind_x64.efi330. To save it.

I copied x64_RefindPlus_DBG.efi from the 142AD downloaded folder to /refind.

I renamed /refind/x64_RefindPlus_DBG.efi to /refind/Refind_x64.efi. Now going to boot DIRECTLY to 142AD debug.

I rebooted.

[dakanji]

To be honest, I don't understand all these different directories you are listing and renaming. Basically, got too much going on to try to wrap my head around intricacies of anyone's setup.

I just asked for one efi file you said was working to be temporarily disabled, replaced with another named with same name and then booted exactly as the original was.

This has apparently been too difficult to do and we are talking about nvRAM and moving/changing multiple files and folders.

We really need to end this discussion as it is fruitless and not going anywhere.

[MarioG-X]

I want to thank you so much for your efforts over the years. And especially working on this one quickly even though you had not planned on it. I only put info up because I happened to be working on it thinking you would address it at a later time.

Yes let's drop this issue since it's looks never to be fixed and I have work arounds. However, you mentioned not understanding the multiple directories, but this all started out with one and only one /EFI/refind directory doing the steps you asked as I have done over the previous years. I broke up into multiple directories only since this issue is easier to work on with them. There is something really strange going on and as a programmer I am pretty sure it's only going to be fixed by adding "traps" into code and testing different phases of progress as you have done before. This is clearly not a serious issue for me since I know how to get around it, but it may be for others.

Anyway, THANK YOU for this wonderful upgrade to rEFind, it has saved me countless hours over the years.

[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.