copy from “https://askubuntu.com/questions/760875/any-downside-to-using-refind-instead-of-grub”

==============================================

I maintain rEFInd, so I understand how it works and interacts with Ubuntu pretty well; but I’m also not without my own biases and preferences. (I forked rEFIt into rEFInd because I dislike GRUB 2 and I thought much of what rEFIt did was elegant, but not quite what I needed.)

In most cases, rEFInd works. It’s rare to experience post-boot problems with any boot loader; once the kernel boots, it either works completely or not at all. (There are occasional exceptions to this rule, but as I said, they’re rare.) Thus, if rEFInd boots your system, you needn’t worry too much about follow-on problems. That said, there are advantages and disadvantages to any piece of software, including boot loaders. Compared to GRUB, these points spring to mind concerning rEFInd:

• rEFInd advantages/GRUB disadvantages
  • Because it scans for kernels on every boot, rEFInd is more adaptive and is less reliant on configuration files. This is most important if you’re booting multiple Linux distributions, since in such a setup, you need to take care that the main GRUB’s configuration file knows about changes to the other distribution’s kernels.
  • GRUB’s configuration file format is very complex. It usually works OK because its configuration scripts do the right thing most of the time; but when the scripts get it wrong, fixing it can be a nightmare. Because rEFInd’s configuration files are simpler, it tends to be easier to fix and tweak its configuration.
  • rEFInd has more eye candy, as you point out.
  • rEFInd is more reliable at booting Windows with Secure Boot active. (See this bug report for information on a moderately common problem with GRUB that doesn’t affect rEFInd.)
  • rEFInd can launch BIOS-mode boot loaders; GRUB can’t. For most people, and particularly people with UEFI-based PCs, this isn’t a big deal. Some Mac users need BIOS-mode compatibility to dual-boot with Windows 7, though.
  • rEFInd on a USB flash drive or CD-R can boot an Ubuntu installation that’s become unbootable. There are some caveats and limitations, but even if you don’t use rEFInd on your hard disk, having it on a USB flash drive or CD-R can be a useful emergency tool.
  • GRUB’s configuration scripts can be slow to run. On a complex setup, installing a new kernel can take a minute or more just because these scripts are triggered and they take a ridiculous amount of time to scan the system for kernels and an assortment of boot loaders and to rebuild the configuration file with what’s found. Note that you’ll experience this problem even if you use rEFInd unless you uninstall GRUB (or don’t install it to begin with).
  • When working with Secure Boot, rEFInd always enforces Secure Boot policies. GRUB might or might not do so when launching Linux kernels, depending on the GRUB version in use. (Prior to Ubuntu 16.04, Ubuntu’s GRUB would launch even unsigned kernels. I think that 16.04 tightens that a bit, but I haven’t yet looked into it in detail.)
• rEFInd disadvantages/GRUB advantages
  • GRUB is available as an officially-maintained package in Ubuntu, whereas rEFInd is (for now) available as a third-party package and PPA.
  • If I get hit by a bus, development of rEFInd is likely to stop; but GRUB has many more developers, and will not become abandonware in the near future.
  • GRUB supports more platforms (CPUs and firmware types).
  • GRUB is easier to use in a network-boot environment.
  • GRUB can (in theory) load a kernel from within an LVM or RAID setup or on an encrypted partition; rEFInd can’t do this. (rEFInd can still be used with LVM, RAID, and encrypted setups, but the /boot partition must be separate and unencrypted in such configurations.) Note that I said “in theory” because I know of no distribution that takes advantage of this feature, so it is, to the best of my knowledge, poorly tested.
  • rEFInd’s scans for kernels and boot loaders can take a couple of seconds on each boot, so it may be a bit slower than GRUB to appear. (You can minimize this scanning time by installing only those filesystem drivers you actually need and by keeping the partitions that are scanned uncluttered.)
  • Shim was designed to work with GRUB. Although rEFInd also works with Shim, it’s not Shim’s primary target, so there’s the bizarre naming convention of calling rEFInd grubx64.efi to get Shim to launch it; and you’ll need to add at least one entry to the MOK list to get rEFInd to work with Shim.

In addition to these points, there are occasional system-specific incompatibilities and quirks. Such problems can strike either program, so they aren’t really advantages of one or the other.

It’s possible to set your system up so that rEFInd launches GRUB (or vice-versa), but in most cases you’ll end up getting the worst of both programs, not the best, when you do this. On occasion, though, chainloading in this way is desirable — say, if you want the eye candy of rEFInd and the ability to load a kernel from an LVM, RAID, or encrypted partition.

As to the installation instructions to which you link, they’re overly complex. The simplest way to install rEFInd in Ubuntu is to use the PPA after you install Ubuntu:

sudo apt-add-repository ppa:rodsmith/refind
sudo apt-get update
sudo apt-get install refind

The drawback to this approach is that it’s one big leap. If you prefer to test rEFInd before fully installing it, by all means use the USB flash drive, which will let you see how rEFInd works before making any changes to your hard disk.