rEFInd was not found in the boot options list after apt-get install refind successful

Question

Original problem is every boot ends with

"grub> "

With the current complication that rEFInd refuses to be found in the boot options list after a successful apt-get install, and continues to do so despite the efforts documented below.

[in sixth day of this insanity going on the seventh with no rest in sight. so desperate for help and understanding.]

Machine is a HP110-220z Desktop with an American Megitrends BIOS [In which I have to set or reset the boot order and system security settings each time I reboot a live DVD.]

A Lubuntu 16.1 install over Ubuntu 16.04.1was necissated and performed after using Gparted to remove the windows partitions [leaving the EFI partitition].
[Even with 8 GiB of RAM the dual 1.4 Ghz processors were causing Unity to crawl. ]

• One problem I have not corrected [if it is a problem] is the 1 GiB unasigned section between the EFI sector and the front of HDD sda2.
• sda1 somehow ended up between sda2 and sda5 when I deleted sda3 and sda4. This according to Gparted.
• I tried to create a partition out of that first unassigned 1 Gib, but was warned off because in moving sda2 EFI to create a minimum sized 1.95 Gib partition, I could "make the machine un-bootable."
• I am writing this with the Lubuntu live disk loaded.

Have 9 partitions or primary and logical drives from the dualboot install three years ago in this order:

1 gib unassigned
sda 02 EFI, 360 MiB sda 01 /temp, 40 GiB [Empty]*
sda 05 14.5 GiB [Hidden HP and win Recovery],
sda 06 1.95 GiB Win shared [fat32] contains files pertinate to this effort, reserved for Samba share at this time.
sda 07 /boot, 500 MiB [Empty]*
sda 08 /root, 21 GiB [Empty]*
sda 09 Swap, 2.0 GiB [Empty]*
sda 10 /var, 4.0 GiB [Empty]*
sda 11 /home 413 GiB [Files backed up except for a number where permission was denied [ownership problem]] * Formatted by Lubuntu install

Tried Boot-repair first Boot repair left boot in same state.
Boot repair could not finish
"close all package managers ... because update manager running in background.

The instruction to download then click remind later didn't work because update kept requiring a reboot, which, of course, with a live DVD reboot in order to run boot-repair removed all updates.
"close all package managers ... "

Clicking reboot later, and killing update and stopping or killing update-notifier and rerunning Boot-repair again resulted in
"close all package managers ... "

I can only guess that be background package manager is hidden even from Lubuntu's task manager.

Reinstalled LuBuntu from live disk

still got grub>

So turned to REfind.

lubuntu@lubuntu:/$ sudo apt-get install refind  
Reading package lists... Done  
. . .  

Preparing to unpack .../refind_0.10.4-0ppa1_amd64.deb ...  
Unpacking refind (0.10.4-0ppa1) ...  
Setting up refind (0.10.4-0ppa1) ...  
Installing rEFInd to the ESP...  
Processing triggers for man-db (2.7.5-1) ...  

lubuntu@lubuntu:/$ $ sudo refind-mkdefault  
$: command not found  

lubuntu@lubuntu:/$ sudo refind-mkdefault  
**rEFInd was not found in the boot options list!**  
You should create a rEFInd entry with efibootmgr or by re-installing  
(with refind-install, for example)  
No changes saved.  

[Above and below are the record of a reinstall of refind, by the way]  

lubuntu@lubuntu:/$ sudo efibootmgr  
BootCurrent: 0012  
Timeout: 0 seconds  
BootOrder: 0001,0002,000C,000D,0012,0013,0006,0007,0014  
Boot0001* USB Floppy/CD  
Boot0002* USB Hard Drive  
Boot0006* USB Floppy/CD  
Boot0007* Hard Drive  
Boot000C  UEFI: WDC WD5000AAKX-60U6AA0  
Boot000D  UEFI: WDC WD5000AAKX-60U6AA0  
Boot0012* UEFI: hp      DVD A  DH16AESH  
Boot0013* CD/DVD Drive   
Boot0014* Realtek PXE B03 D00  
lubuntu@lubuntu:/$

USB floppy/CD got in there twice while rEParted did not. Hmmm.

Could find no really detailed step by step instructions for using efibootmgr that I could feel confident in using to add rEFind to the boot list. All seemed to asume a level of programming knowledge I have being a basically hardware man. [in my brain Programming = chemistry = magic. and I'm cursed with being a "Mister Literal"]

No one seems to have had the same exact situation in the last 8 years either in askubuntu, ubuntuforums or elsewhere.

in sixth day of this insanity
and here I am with my little piccilo so to speak.
With a wife who has been very, very.., very...., patient.

Answer 1

Machine is a HP110-220z Desktop with an American Megitrends BIOS

This could be the source of the problem (but see below). Many HPs, and some other brands, have problems in which EFI boot entries are forgotten or ignored. See, for instance:

• boot-repair not working on hp elitebook 2170
• How do I get my HP laptop to boot into grub from my new efi file?
• What should I do to get Ubuntu dual-boot with Windows 10 on this Toshiba laptop?

The answers to these questions provide information on bypassing the problem.

One problem I have not corrected [if it is a problem] is the 1 GiB unasigned section between the EFI sector and the front of HDD sda2.

There's no such thing as an "EFI sector." I assume you mean the first sector of the disk, aka the Master Boot Record (MBR). Most partitioning tools these days align partitions on 1 MiB (2048-sector) boundaries by default, which leaves a close-to-1MiB gap at the start of the disk. Note that's MiB, not GiB, though. If you've truly got a 1 GiB gap, then chances are you deleted something from the start of the disk. You should be able to create something new there if you're using the GUID Partition Table (GPT); however....

Have 9 partitions or primary and logical drives from the dualboot install three years ago

The concepts of primary and logical partitions are unique to the MBR partitioning scheme. Under GPT, there's no such distinction; GPT simply supports partitions, full stop. Some partitioning tools insist on calling all GPT partitions "primary," but that's because these tools were originally designed for MBR, and in trying to shoehorn GPT into an MBR model, partitions must be called "primary," "extended," or "logical," so the program calls GPT partitions "primary" because that's the least-wrong choice -- but it's still technically inaccurate. If your disk really has primary and logical partitions, then that means it uses MBR. This is fine as far as it goes; however, it could be the source of both of the preceding problems:

• Although EFI permits booting from MBR disks, some EFIs have a hard time recording boot entries that point to MBR disks. Thus, if you're using an MBR disk, that might be the reason you can't get an EFI boot entry to GRUB or rEFInd to "stick" in the firmware.
• MBR has a 4-primary-partition limit, so if the disk already has four primary partitions (or three primaries and an extended partition), then you won't be able to create additional primary partitions. The very start of the disk is likely to require a primary partition, so this could be the cause of your inability to create a partition in this space. That said, your partition list specifies a partition #2 and then partitions #5 and up. Even if you omitted the extended partition, that leaves two primary partitions available, so the only way the 4-primary-partition limit would be a factor is if you've omitted two partitions from your partition list.