Adopting RefindPlus on Linux-Only Multiboot Setup

[DavidInRacine]

I am not having any problem with rEFInd on my Linux laptop, however I developed an interest in possibly replacing it with Refind Plus for added functionality. I tried using the Docker installation method described by Dmitrii Okunev (https://github.com/xaionaro/) however I did not have much success with that approach, nor with Dakanji's instructions at
https://github.com/dakanji/RefindPlus/blob/GOPFix/BUILDING.md

Does anybody have step-by-step instructions that are confirmed to work under Debian or Arch based Linux distros, or ideally a refind_x64.efi binary I can copy into /EFI/refind in my boot partition?

(Mac OS users have it easy with MyBootMgr.)

Thank you in advance.

[dakanji]

You can find RefindPlus binaries under the "Releases" tab of this repo: https://github.com/dakanji/RefindPlus/releases

[DavidInRacine]

Thank you dakanji! Your binaries worked (sort of) on my linux laptop.

For the benefit of other Linux users, here is what I did step-by-step to convert my rEFInd boot volume to a Refind Plus boot volume:

(1) I opened my REFIND boot partition (SSD volume #1) using GNOME Disks
(2) On vol #1 I renamed /REFIND/EFI/refind/drivers_x64/ext4_x64.efi to drivers_x64/ext4_x64.efi.bak
(3) I copied all the files from Refind Plus' "OtherBinaries" folder into /REFIND/EFI/refind/drivers_x64/
(4) I duplicated and renamed my refind.conf file to config.conf
(5) I renamed refind_x64.efi to refind_x64.efi.bak
(6) I copied RefindPlus_x64-DBG.efi into my /REFIND/EFI/refind/ folder and renamed it refind_x64.efi
(7) I rebooted and watched Refind Plus take over the startup process

I will now return to using rEFInd for the following three reasons:

(A) Refind Plus requires me to answer two questions at every startup, the first of which is a nuisance and the second is DANGEROUS. The first question follows this statement: "Ordinarily, a hybrid MBR (which this program creates) should be used ONLY on Apple Macs that dual-boot with Windows or some other BIOS-mode OS. Are you SURE you want to continue [y/N]"

The second question offers to obliterate four of my eight SSD partitions, which contain shared user data and experimental distros: "May I update the MBR as proposed above? [n/Y]"

Inadvertently answering yes to both questions would cause a disaster on my multi-boot system... I cannot risk this happening. At best, I would waste time restoring from my last SSD clone. At worst, I would lose important data.

(B) A minor complaint, but a UI downgrade from rEFInd and a time waster -- none of my custom Linux volume icons at the root of each distro's partition (ie, /.VolumeIcon.png ) shows up on the RefindPlus boot screen. All distro icons have identical penguin icons in Refind Plus, which is cosmetic but it slows me down to make sure I am booting the right distro -- I have to read the text instead of clicking a familiar icon.

(C) Refind Plus takes at least 2-3 times as long to boot as rEFInd, especially considering the points (A) and (B) above and not wanting to wipe out my four shared partitions.

I am willing to beta test Refind Plus in the future, but for now I will roll-back to Roderick Smith's version. rEFInd works without any babysitting.

That said, I think you are doing terrific work for the Mac community. It just seems Linux is the forgotten stepchild of Refind Plus. A few simple fixes could make it equal to or better than rEFInd for non-Mac OS users, but we're not there yet.

I hope you have no hard feelings regarding unvarnished feedback from a Linux user. I see you are working incredibly hard to make it a success. I look forward to using Refind Plus on my old Mac, and maybe again on my Linux machine sometime in the future.

Respectfully submitted.

[DavidInRacine]

BTW, what is the difference between the two binaries?... RefindPlus_x64-DBG.efi and RefindPlus_x64-REL.efi

I used the larger RefindPlus_x64-DBG.efi on an uneducated hunch that it was less likely to brick my system (525 vs 366 KB).

Thanks again.

[DavidInRacine]

Responding to myself, an easy work-around to the DANGEROUS issue (A) above... I removed x64_gptsync.efi (renamed it to x64_gptsync.efi.bak) and Refind Plus booted straight to the startup screen. Custom Linux distro icons are still absent, but I can live with that temporarily if you want me to keep testing Refind Plus.

[startergo]

I am not having any problem with rEFInd on my Linux laptop, however I developed an interest in possibly replacing it with Refind Plus for added functionality. I tried using the Docker installation method described by Dmitrii Okunev (https://github.com/xaionaro/) however I did not have much success with that approach, nor with Dakanji's instructions at https://github.com/dakanji/RefindPlus/blob/GOPFix/BUILDING.md

Does anybody have step-by-step instructions that are confirmed to work under Debian or Arch based Linux distros, or ideally a refind_x64.efi binary I can copy into /EFI/refind in my boot partition?

(Mac OS users have it easy with MyBootMgr.)

Thank you in advance.

Where do you experience issues in the xaionaro build? If you just clone the project, navigate to the RefindPlus folder and drop build.sh in terminal it should automatically build RefindPlus

[DavidInRacine]

The Xaionaro build was unable to complete installation due to its inability find or create various directories. After a couple hours messing around I gave up.

Also, this appears to be an older version of Refind Plus. For anyone wanting to test Refind Plus on a linux machine, Dakanji's binaries appear to be the easiest way to go.

[startergo]

https://github.com/xaionaro/

The Xaionaro build was unable to complete installation due to its inability find or create various directories.

You must be doing something wrong. I just installed Docker and issued these commands:

git clone https://github.com/xaionaro/edk2-builder-docker.git
Cloning into 'edk2-builder-docker'...
remote: Enumerating objects: 326, done.
remote: Counting objects: 100% (162/162), done.
remote: Compressing objects: 100% (72/72), done.
remote: Total 326 (delta 112), reused 113 (delta 84), pack-reused 164
Receiving objects: 100% (326/326), 61.56 KiB | 1.37 MiB/s, done.
Resolving deltas: 100% (160/160), done.
mbp151@MBP151s-MBP ~ % cd edk2-builder-docker 
mbp151@MBP151s-MBP edk2-builder-docker % cd examples 
mbp151@MBP151s-MBP examples % cd github.com-dakanji-RefindPlus 
mbp151@MBP151s-MBP github.com-dakanji-RefindPlus % ./build.sh 
............................
.............................
.............................

- Done -
Build end time: 16:40:07, Jul.05 2023
Build total time: 00:00:35

[startergo]

Also, this appears to be an older version of Refind Plus

The docker image downloads the latest source code from the repo and builds the latest code. You will not find that in the releases of RefindPlus. You have to build them manually as described in the RefindPlus repo or use the docker image for automation.

[dakanji]

The tool is called RefindPlus. Without a space inbetween.

Here is what I did step-by-step to convert my rEFInd boot volume to a Refind Plus boot volume

This is already succinctly outlined under installation in the Repo's ReadMe as follows:
Install rEFInd and replace the rEFInd binary with the RefindPlus binary.

RefindPlus requires me to answer two questions at every startup, the first of which is a nuisance and the second is DANGEROUS.

RefindPlus does NOT require any questions to be answered on booting whatsoever.

The first question follows this statement: "Ordinarily, a hybrid MBR (which this program creates) should be used ONLY on Apple Macs that dual-boot with Windows or some other BIOS-mode OS. Are you SURE you want to continue [y/N]"

This question is not from RefindPlus, but from a totally different binary called gptsync. If you run gptsync in rEFInd, as is possible, you will get exactly the same question.

The second question offers to obliterate four of my eight SSD partitions, which contain shared user data and experimental distros: "May I update the MBR as proposed above? [n/Y]"

Ditto

Inadvertently answering yes to both questions would cause a disaster on my multi-boot system... I cannot risk this happening. At best, I would waste time restoring from my last SSD clone. At worst, I would lose important data.

The real question here is why you are running gptsync in the first place if you are not looking to amend your partitions.

A minor complaint, but a UI downgrade from rEFInd and a time waster -- none of my custom Linux volume icons at the root of each distro's partition (ie, /.VolumeIcon.png ) shows up on the RefindPlus boot screen. All distro icons have identical penguin icons in Refind Plus, which is cosmetic but it slows me down to make sure I am booting the right distro -- I have to read the text instead of clicking a familiar icon.

You should have read the Readme to see divergences from rEFInd. I have reproduced the pertinent bit below:

Loader Icons: RefindPlus always prefers generic default theme icons for loaders ahead of custom icons, where 
possible, to improve loading speed. Such icons typically used but the inherited icon search involves only using 
such after a search for custom icons has not turned anything up. Users that prefer not to use this feature can 
activate the RefindPlus-Specific decline_help_icon configuration token to switch it off.

In summary, unlike rEFind which looks for custom icons first and only loads generic ones if not found (slowing things down for the majority of users), RefindPlus will look for generic icons first and use these if found. If you do not want this, set the decline_help_icon configuration token. (unwritten is "or remove the generic icons").

RefindPlus takes at least 2-3 times as long to boot as rEFInd

Not a surprise since what you described as an uneducated hunch led you to use the DEBUG (DBG) build instead of the RELEASE (REL) build. It does appear that you are not alone in not being familiar with what REL and DBG stand for though. I just fielded a similar query recently: #162

wanting to wipe out my four shared partitions.

RefindPlus does not delete partitions but YOU have set things up to run something else that does this instead.

It just seems Linux is the forgotten stepchild of RefindPlus. A few simple fixes could make it equal to or better than rEFInd for non-Mac OS users, but we're not there yet.

That is a mistaken view based on several missteps on your part but the key thing is to use whatever works for you.

I hope you have no hard feelings regarding unvarnished feedback from a Linux user.

Absolutely none whatsoever. I very much prefer unvarnished communication.
The feedback just happens to be inaccurate in every respect and therefore, ultimately useless.

[DavidInRacine]

You did not see it, but I uninstalled x64_gptsync.efi before your last message. GPTsync is truly dangerous. I did not know it was external to RefindPlus since it was included in your binaries. GPTsync caused the majority of the slowdown, and my righteous fear.

I reverted to rEFInd and all is well. Glad to see you are supporting that project too, or at least it has your name on it.

https://github.com/dakanji/rEFInd

The Arch repository is another good source for rEFInd binaries and documentation. It's also available via Manjaro's Software Update. I did not find RefindPlus at any of those places.

rEFInd appears to offer everything most Linux users would need except for gdisk support, but gdisk error-messaged for me under RefindPlus too -- so no advantage there vs rEFInd.

The eye candy of loader icons is a positive for users running several Linux distros where icons can change position when external drives are attached. [Maybe loader icons don't matter as much in Mac OS?] rEFInd delivers loader icons beautifully.

Whether you find my observations useful or not, they are what I experienced. I presented them accurately and in a straight-forward manner. For now I'll stick with rEFInd. Others are free to choose.

[dakanji]

[Maybe loader icons don't matter as much in Mac OS?]

I suppose you are making the quite understandable mistake, given the frequent mentions of Mac OS, of thinking a project targeting some specific HARDWARE that happens to be made by Apple equates to targeting the OPERATING SYSTEM made by Apple.

The mistake is understandable because someone that has not had the privilege of running 3,1 to 5,1 Classic MacPros would not realise that they are equally at home running Mac OS, Windows or Linux and that many users of that hardware run all three. The focus is on the hardware and all the OS they run.

Whether you find my observations useful or not, they are what I experienced. I presented them accurately and in a straight-forward manner.

I do realise they are what you experienced and I can list them out since you did set them out in a straight forward and accurate manner:

1. You experienced slowness
2. You experienced weird/dangerous questions
3. You experienced default icons always loading instead of your preferred ones

What was inaccurate, was that these were problems

1. Slowness: You chose to run a debug build (for troubleshooting) instead of a release build (for regular use)
2. Weirdness: You chose to run a binary for deleting partitions
3. Icons: You chose not to read instructions on how to get custom icons instead (or any other instructions it seems)

I did appreciate the feedback as said. I just gave an unvarnished assessment of this based on the reasons why you got the outcomes you got (all down to your decisions).

Either way, as it seems you are not able to wrap your head around some of the paradigms, it is better indeed to stick with what you feel happy with.

Thanks again!

[dakanji]

I did not know it was external to RefindPlus since it was included in your binaries.

GPTsync is included in a separate folder called Other Binaries along with several others ... is that not clearly separate?

The instruction was to install rEFInd and replace the rEFInd efi file (a single file) Not sure how some other binary that you do not know what it does got into that picture.

BTW, I suppose you have never built rEFInd from scratch as GPTsync is built along with rEFInd ... this was just inherited by RefindPlus

gdisk error-messaged for me under RefindPlus too -- so no advantage there vs rEFInd.

The error should have been fixed in RefindPlus but haven't tried it for quite a while.
Will look at it again soon. Perhaps a regression has happened ... That is useful feedback. Thanks.

[DavidInRacine]

My goal in posting these musings was NOT to create a family feud. RefindPlus and rEFInd are what? -- Half siblings? First cousins? Parent-child?

I am also not trying to stir up trouble between Linux and Mac OS communities. I have been a Mac owner since 1985 and an Apple II+ owner since 1980. I used to write assembly language on Apple hardware, but that was a long time ago. I intend no hostility between OS communities, nor between users and developers.

My goal was to provide a case #1 of a guy who migrated from rEFInd linux bootloader (and happily so) this morning to RefindPlus. Had I started with RefindPlus instead of rEFInd, my comfort level with it would likely have been better, as would my motivation to probe deeply into its advanced features.

Both rEFInd and RefindPlus offer HUGE improvements over GRUB2. From the end-user's standpoint, the differences between them are subtle, whereas rEFInd and RefindPlus both offer significant improvements over GRUB.

I probably could have figured out how to make icons work in RefindPlus had I invested more time. Installing GPTsync was a rookie mistake. I dragged the entire folder over without giving any thought about the contents. I should have known better.

Dakanji, I believe you are doing all you can do to make booting multiple OSes easier, and for that I salute your efforts.

Hopefully these dialogues benefit people to make better informed decisions how to invest their time and what to do / what not to do.

Advice:

(1) Maybe Linux users should start with RefindPlus before trying rEFInd? Though similar, both projects involve separate learning curves. Mistakes will happen along the way. Eventually you find what works for you.

(2) Keep multiple backups - you're likely to need them. A bricked startup is almost guaranteed when you're messing with bootloaders such as GRUB and rEFInd / RefindPlus.

(3) Read as much as you can before starting, then read some more. A lot is written between-the-lines, either undocumented or scattered across various web pages.

In retrospect, DBG should have been clear enough. REL now obviously means "release." It didn't click for me this morning, but now it does. Linux users expect this type of documentation and the consequences that follow from not understanding. Mac OS users generally don't. I am somewhere in-between these communities, and learning.

[dakanji]

trouble between Linux and Mac OS communities

While you tend to see things in terms of Linux and Others, many users run Linux and the others together. One minute, they are on Linux and the next, something else. They are neither Linux Users nor Other Users.

I also saw a description of rEFInd as the rEFInd Linux Bootloader which is wrong. It loads Linux and multiple others ... same as RefindPlus (which is simply rEFind with some fixes and additional items).

(1) Maybe Linux users should start with RefindPlus before trying rEFInd? Though similar, both projects involve separate learning curves.

It doesn't really matter what is used first but the expectation with RefindPlus is that most would default to rEFInd first since this is likely to work just fine in most cases (There are issues on Classic MacPros but this is a small subset) and while intermediate to advanced users will know how to set things up manually, rEFInd will likely be available in linux package managers and such.

If they decide to try RefindPlus, they will find it is 90% like rEFInd apart from a handful of items where there is divergence. These are clearly listed out in the ReadMe file and "rEFInd type" behaviour can be implemented if desired instead. There is no different learning curve to speak of.

(2) Keep multiple backups - you're likely to need them. A bricked startup is almost guaranteed when you're messing with bootloaders such as GRUB and rEFInd / RefindPlus.

Users should have a recovery plan in place indeed but a broken startup is not almost guaranteed. Having said that, I suppose that yes, it is a distinct possibility. I test new RefindPlus files (as you can imagine, I need to this quite a bit) by loading them from a known working instance.

Boot -> Known Working Instance -> Instance for Testing

If it fails, I simply restart and the working instance runs.
The known working instance could be rEFInd for someone wanting to test RefindPlus having already implemented the former.

(3) Read as much as you can before starting, then read some more.

Definitely the case