Clarification as to why certain boot loaders were discovered (OSX/Ubuntu)

[Nap]

I've been running rEFInd for a while now on my MacBook Pro (2014) (Intel i7), and am very satisfied. My only complaint is that MacOS and Ubuntu should respect the owner of the computer and not 'Boot Coup' after certain updates.

I've been busy with studies for a while now which required using OSX, and thus have been holding off upgrading my U16 partition to U18. I've also been holding off on the upgrade because I don't tinker with the boot process often and did not want to risk any failures.

A few days ago, in preparation for the U18 upgrade, I first brought my MacOS up-to-date (Mojave/Xcode10). I then moved my U16 install from an internal partition on the Mac to an external hard drive (item 8 in the list below) and then installed a fresh U18 on the internal partition. Whilst doing these things, I chose to update rEFInd using the Ubuntu package, and added shellx64.efi from the CD image. All my installs, and rEFInd, are working fine and now I would like to tweak it to my liking.

After reading almost all of the rEFInd documentation pages, I'm now trying to configure rEFInd to only show boot loaders that are relevant to me. Whilst I understand how a computer boots at a high level, I am a novice when it comes to Grub, sysLinux, etc and other boot loaders/shells. (Another words, I know enough to get by, but 'm not an expert, so please be gentle.)

It seemed natural to use the automatically detected loaders as a starting point. However, I don't understand why some of the automatically detected loaders are being displayed in the first place. In conjunction with the picture below, the boot loaders found are:
1) EFI\ubuntu\shimx64.efi from EFI
2) EFI\Boot\fbx64.efi from EFI
3) boot\vmlinuz-4.15.0-39-generic from "HD-U1804"
4) macOS from Preboot
5) macOS from HD-OSX
6) Linux (Legacy) from whole disk volume
7) Linux (Legacy) from FAT volume
8) boot\vmlinuz-4.10.0-33-generic.efi.signed from "HD-U1604" <= not show in image, was not plugged in
Note, from the picture, I'm using the partition label to determine the displayed icon.

I don't understand why:
(1) is displayed at all as I am not using "Secure Boot" nor are any partitions encrypyted. (Note that loader (8) is not present in the image below, yet item (1) was still shown.) If I select this option, the loader starts but fails and I have to power cycle my Mac.
(2) is being displayed at all. The "Managing Boot Coups with fallback.efi/fbx86.efi" section of the manual is not applicable. rEFInd boots each time to the menu without any issues.
(3) is shown as loading from \boot\vmlinuz... instead of EFI\ubuntu\grubx64.efi (since I have Grub2 installed and configured).
(6) & (7) Why are these showing, and how do I make them go away via the config file?
(8) [when plugged in] is showing \boot\vmlinuz? This disk does not have a separate (or its own) EPS partition.

I would also appreciate further explanation of what "Preboot" (4) is and why my MacOS is now on a synthisized partition called "Container disk1", as I'm still confused after reading about it on StackOverflow. Perhaps a link to some authorative information?

Thanks for "rEFInd" and taking the time to answer my questions,
Nap.

EFI/refind/BOOT.CSV has one entry:
refind_x64.efi,rEFInd Boot Manager,,This is the boot entry for rEFInd

Partition information (from MacOS)

    user@host:[16:58]$ diskutil list
    /dev/disk0 (internal, physical):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *500.3 GB   disk0
       1:                        EFI EFI                     209.7 MB   disk0s1
       2:                 Apple_APFS Container disk1         300.0 GB   disk0s2
       3:                  Apple_HFS Recovery HD             650.0 MB   disk0s3
       4: FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF               1.0 MB     disk0s4
       5:                 Linux Swap                         17.4 GB    disk0s5
       6:           Linux Filesystem                         182.0 GB   disk0s6

    /dev/disk1 (synthesized):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      APFS Container Scheme -                      +300.0 GB   disk1
                                     Physical Store disk0s2
       1:                APFS Volume OSX                     261.0 GB   disk1s1
       2:                APFS Volume Preboot                 42.0 MB    disk1s2
       3:                APFS Volume Recovery                512.8 MB   disk1s3
       4:                APFS Volume VM                      1.1 GB     disk1s4

    ~
    user@host:[16:58]$ df -kt
    Filesystem    1024-blocks      Used Available Capacity iused               ifree %iused  Mounted on
    /dev/disk1s1    292968748 254867004  36371772    88% 4906108 9223372036849869699    0%   /
    devfs                 378       378         0   100%    1313                   0  100%   /dev
    /dev/disk1s4    292968748   1048600  36371772     3%       1 9223372036854775806    0%   /private/var/vm
    /dev/disk0s3       634768    509684    125084    81%      20          4294967259    0%   /Volumes/Recovery HD
    map -hosts              0         0         0   100%       0                   0  100%   /net
    map auto_home           0         0         0   100%       0                   0  100%   /home
    /dev/disk0s1       201633     59352    142281    30%       0                   0  100%   /mounts/EFI
    ~
    user@host:[16:58]$ diskutil apfs list
    APFS Container (1 found)
    |
    +-- Container disk1 <GUID1>
        ====================================================
        APFS Container Reference:     disk1
        Size (Capacity Ceiling):      299999997952 B (300.0 GB)
        Capacity In Use By Volumes:   262755303424 B (262.8 GB) (87.6% used)
        Capacity Not Allocated:       37244694528 B (37.2 GB) (12.4% free)
        |
        +-< Physical Store disk0s2 <GUID2>
        |   -----------------------------------------------------------
        |   APFS Physical Store Disk:   disk0s2
        |   Size:                       299999997952 B (300.0 GB)
        |
        +-> Volume disk1s1 <GUID3>
        |   ---------------------------------------------------
        |   APFS Volume Disk (Role):   disk1s1 (No specific role)
        |   Name:                      OSX (Case-insensitive)
        |   Mount Point:               /
        |   Capacity Consumed:         260983812096 B (261.0 GB)
        |   FileVault:                 No
        |
        +-> Volume disk1s2 <GUID4>
        |   ---------------------------------------------------
        |   APFS Volume Disk (Role):   disk1s2 (Preboot)
        |   Name:                      Preboot (Case-insensitive)
        |   Mount Point:               Not Mounted
        |   Capacity Consumed:         42016768 B (42.0 MB)
        |   FileVault:                 No
        |
        +-> Volume disk1s3 <GUID5>
        |   ---------------------------------------------------
        |   APFS Volume Disk (Role):   disk1s3 (Recovery)
        |   Name:                      Recovery (Case-insensitive)
        |   Mount Point:               Not Mounted
        |   Capacity Consumed:         512761856 B (512.8 MB)
        |   FileVault:                 No
        |
        +-> Volume disk1s4 <GUID6>
            ---------------------------------------------------
            APFS Volume Disk (Role):   disk1s4 (VM)
            Name:                      VM (Case-insensitive)
            Mount Point:               /private/var/vm
            Capacity Consumed:         1073766400 B (1.1 GB)
            FileVault:                 No
    ~
    user@host:[16:59]$

[Roderick W. Smith]

By default, rEFInd should hide shimx64.efi on x86-64/AMD64/X64 platforms. If it's showing up, then that suggests that either you're on some other architecture and somehow have a shimx64.efi file present or that you've overridden the dont_scan_files option in refind.conf. The latter is far more likely. If you want to use dont_scan_files, either use + as the first item in the list to preserve the defaults and add to them, or add in whatever you don't want to be scanned, including defaults like shimx64.efi. Note that shimx64.efi should boot correctly through GRUB in the same directory, even if the computer does not support Secure Boot. If that's not happening, perhaps you've deleted that file, or perhaps there's a bug somewhere (in rEFInd, in Shim, in GRUB, or elsewhere).

Similar comments apply to fbx64.efi; that's on the default dont_scan_files list.

rEFInd can launch Linux kernels that include the EFI stub loader directly, without using GRUB. That's why your boot\vmlinuz-4.15.0-39-generic from "HD-U1804" item is booting without involving GRUB. If you don't want to use this feature, you can uncomment scan_all_linux_kernels and set it to false in refind.conf. Then, rEFInd will not show options for individual Linux kernels (unless they have .efi filename extensions), but it will show options for GRUB -- if GRUB is installed and not disabled via dont_scan_* options. (Aside from the option to launch through Shim, I don't see any GRUB options in your menu. Perhaps you removed them via a dont_scan_* option, or maybe an EFI-mode GRUB isn't fully installed on your ESP.) Most rEFInd users prefer booting kernels via the EFI stub loader rather than GRUB, at least most of the time.

The Legacy options refer to boots via the firmware's BIOS/CSM/legacy mode support. You can disable them by uncommenting the scanfor option in refind.conf and ensuring that hdbios is not among the options. This is the default for UEFI-based PCs; however, Macs default to including BIOS-mode boot options because many (increasingly older) Windows installations rely on this support. It appears that you don't need it. It's possible that you installed Linux in BIOS mode and one or both of these options is launching Linux in this way, which could explain why GRUB isn't showing up directly in your menu.

Apple, in its infinite wisdom, has moved the location of its boot loader several times in the last two or three years, and sometimes a system may have multiple redundant macOS boot loaders installed. Unfortunately, this means that rEFInd must scan for macOS boot loaders in multiple locations. When it finds two macOS boot loaders, it's impossible for rEFInd to know if they're redundant, if one or more is broken, or if they boot separate macOS installations. Thus, rEFInd defaults to presenting everything it finds. If you want to reduce this clutter, you can hide whichever loaders you don't want to use, as described in the rEFInd documentation. Note that the same techniques can be used to hide other boot entries you don't want to see, instead of adjusting refind.conf; however, I recommend doing as much as you can in refind.conf rather than using dynamic partition hiding, if possible, so as to minimize wear and tear on your NVRAM.

[Nap]

Thanks for the info Rod!

My shimx64.efi came via the Ubuntu package I used to install rEFInd. I made it, and fbx64.efi go away by using dont_scan_files as you suggested.

As I'm using an extended keyboard (from a PowerMac), the delete key between the main kbd and numpad allowed me to hide things. As I hid things, rEFInd told me some info about the item in question. So my next step will be to use that info to hide them via the refind.conf file, and preserve my NVRAM.

I've now disabled hdbios as I've been installing Linux using EFI.

My refind.conf file did not have a template entry for dont_scan_tools. (Probably because it came from an older version.) Since I've left my showtools at its default setting, the MoK and FWupdates tools were showing. I found I needed to hide them twice, once to keep them from showing in the top list, using dont_scan_files, and again, using dont_scan_tools, to keep them out of the bottom list.