rEFInd is removed whenever hdd is disabled from firmware(BIOS).

[JH Park]

Hello.
First, thank you for your great software.

I'm using the latest version of refind(0.10.5) from the ppa.
Here's my system summary.

Main Board : Gigabyte b85n phoenix (UEFI mode only)
HDD(SDD) :
1st : Ubuntu 16.04(Unity) - Grub only
2nd : Windows 10 - Windows Boot manager only
3rd : Kubuntu 17.04 and Ubuntu Budgie on separate partitions, both Grub and rEFInd are installed.

I only use those drivers one at a time. I mean, if I use Ubuntu, I only use(enable) 1st drive, and disable the other two drives in the firmware(BIOS). And if I use Windows, the other two drives are disabled...

Here comes the problem.
On the 3rd drive, I installed both Kubuntu and Ubuntu Budgie in separate partitions(/dev/sda2, /dev/sda3). And I also installed refind as a boot manager, and it works fine. I could choose Kubuntu or Budgie using rEFInd and there's no problem at all.

However, if I disabled the 3rd drive and enable the others(1st or 2nd drive) in the Gigabyte's firmware, and then I come back to the 3rd drive(3rd drive is on, the others are off), rEFInd is gone, and only Grub is working.

This is 'efibootmgr -v' when refind is working.

BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0000,0001
Boot0000* rEFInd Boot Manager   HD(1,GPT,102ba875-feab-48a3-b575-15f361570ed8,0x800,0x64000)/File(\EFI\refind\refind_x64.efi)
Boot0001* ubuntu        HD(1,GPT,102ba875-feab-48a3-b575-15f361570ed8,0x800,0x64000)/File(\EFI\Ubuntu\grubx64.efi)

This is 'efibootmgr -v' when refind is gone.

BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001
Boot0001* ubuntu        HD(1,GPT,102ba875-feab-48a3-b575-15f361570ed8,0x800,0x64000)/File(\EFI\Ubuntu\grubx64.efi)

I could reinstall refind by 'refind-install' command, but it's very annoying.

What could I do?
Thanks in advance.

[Roderick W. Smith]

Your firmware is deleting invalid EFI boot entries when you remove the drive that contains them. This is a common feature -- no doubt manufacturers think it's helpful because they haven't considered your use case. I can think of four solutions:

• Get a new firmware -- This isn't really a practical solution in the short term, but you could try lobbying manufacturers to make their firmware not delete invalid boot entries, or at least make this feature something you can toggle off in the firmware settings.
• Stop removing your disks -- It's not clear from your description why removing your disks is necessary. Windows should ignore the Linux partitions (if it doesn't, the type code may be set incorrectly), and you can easily configure Linux distributions to ignore the Windows partitions, as well as each others' partitions.
• Rename rEFInd to a fallback filename -- You can move/rename rEFInd to use a fallback filename, either EFI/BOOT/bootx64.efi or EFI/Microsoft/Boot/bootmgfw.efi. The mvrefind script that comes with rEFInd will help you do this. When the firmware can't find any other bootable device, it will normally fall back on one of these filenames. One limitation of this approach is that, if you try to boot with both the Windows disk and one of the Linux disks installed, the computer might decide to boot Windows, which may not be what you want.
• Install a bouncer -- A simple "bouncer" boot loader can redirect the boot process from a fallback filename to rEFInd. I'm pretty sure that the new fbx64.efi boot loader that's started to show up on Ubuntu systems is such a tool, but I have yet to study it closely. rEFIt came with one called bounce.efi, but I never bothered to compile it when I forked rEFInd. I may look into this, though. Note that fbx64.efi, if I understand correctly, launches EFI/ubuntu/grubx64.efi, so it won't be useful by itself unless you rename rEFInd to that name. You'd need to modify and recompile one of these programs to get it to launch EFI/refind/refind_x64.efi. Also, use of a bouncer suffers from the same caveat as renaming rEFInd to the fallback filename -- the firmware might favor booting Windows if both disks are installed.

Note that Windows might continue to boot, and therefore not seem to suffer from this problem, because many EFIs treat the Windows boot loader (EFI/Microsoft/Boot/bootmgfw.efi) as a sort of fallback filename. Thus, when the Windows entry disappears, it's either added back automatically or the system boots from that filename if it's present, even in the absence of an explicit boot entry.

Personally, I'd simply stop removing the disks. That trick was common in the BIOS era, and although it does have the advantage of reducing the risk of one OS accidentally trashing another disk's data, it also creates other problems and risks, such as the one you're encountering now. Keeping adequate backups can protect you against cross-OS accidents and will protect against other problems (a hard disk that goes belly-up, a within-OS accident, etc.).

[JH Park]

Thank you for your answer, Mr. Smith.
I do remove drives on purpose. I just don't want to be hassled with other disks(and partitions) that I don't need at that time. Well, it reduces possible accidents, I think. ;-0

I'll try the 3rd solution you suggested. There's no Windows on the disk, it might be the best way for me, if it work well.

I'll be right back with a result.
See you in a bit!

[JH Park]

mvrefind gave me the solution.

mvrefind /boot/efi/EFI/refind/ /boot/efi/EFI/BOOT

As a result, /boot/efi/EFI/refind/ moved to /boot/efi/EFI/BOOT. But not only just 'move' the directory, but also filename is changed.

/boot/efi/EFI/refind/refind_x64.efi --> /boot/efi/EFI/BOOT/bootx64.efi

For me, this is the easiest and fastest solution.
Thanks again.