UEFI Boot Process - Sanity Check

Question

I'm trying to get my head around the "boot process" (Not necessarily linux), and I'll be glad if someone can confirm my understanding so far, with relation to some experience I'm having.

BIOS - MBR
As far as I understand, the boot process on BIOS machines is as follows: BIOS is a firmware that uses a non-volatile memory to store the order of disks that it will try to boot from when the computer starts up. It will then go to the first, and if it will find a valid MBR code, it will pass control to that code. The MBR code will then do the work of loading the OS. In the case of GRUB, Stage 1 (boot.img) will be in the MBR, passing control to Stage 2 (core.img which will be located on the empty space between the MBR and the first partition), which will locate and load the kernel, passing control to the kernel.

On GPT partitioned disks, the core.img will be on it's own partition.

UEFI - GPT
UEFI is working in a different way. It doesn't rely on the first sector of a disk. Instead, in a UEFI system, the bootloaders will take the form of .efi files, placed in the EFI System Partition. So Windows will have its own .efi file in this partition, and Linux will have its own.
The UEFI firmware is smart enough to understand the FAT filesystem, so it can locate those efi files by path names, and those bootloaders are the ones that will load the appropriate kernel.

The experience I'm having is this: I got a brand new PC with Windows 10 on. Now I wanted to install Ubuntu 20 on a USB, so whenever I like I can just plug the USB and boot Ubuntu instead of Windows (I just didn't want it to take space from my hard drive). Done it using this guide. When I plugged the USB, I got to the GRUB menu, letting me select what OS I want to boot. Great. When I powered my PC without the USB inside, I got to the GRUB rescue shell, which only after typing exit the computer booted Windows. I then noticed that in my ESP (in the drive) I had a directory named ubuntu, which is where GRUB is.

My UEFI is configured in this order:

1. USB Flash Drive
2. Ubuntu
3. Windows

So trying to understand this phenomena based on the theory above, what happens is that: UEFI firmware has its order of targets to boot from (much like BIOS has), in my case Ubuntu is before Windows. UEFI somehow knows that this Ubuntu resides on a USB drive, so when the USB is not connected, it prompts with the rescue shell. Is that correct?

Questions I have regarding to all this:

1. That menu that GRUB gives - Is that part of the bootloader? If it is, why doesn't it show up even though the USB is disconnected? It should realize that it's disconnected only after I select ubuntu
2. When I first plugged the Live CD to install ubuntu. That Live CD is formatted with a MBR bootloader code right? How does EFI treat that? Can you boot normally in the old BIOS/MBR scheme with EFI? (Even if your EFI is not configured that way, I know there's a way to configure it that way).

It will be great if someone could confirm my understanding/misunderstanding of all this.

EDIT This is the output of:

/boot/efi/EFI/ubuntu$ efibootmgr -v
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0019,0001,0000,0015,0016,0017,0018,001A,001B,001C,001D
Boot0000* Windows Boot Manager  HD(1,GPT,d37539b4-7745-44f3-83b4-59b5ff5dc08f,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...e................
Boot0001* ubuntu    HD(1,GPT,d37539b4-7745-44f3-83b4-59b5ff5dc08f,0x800,0x82000)/File(\EFI\ubuntu\shimx64.efi)
Boot0010  Setup FvFile(721c8b66-426c-4e86-8e99-3457c46ab0b9)
Boot0011  Boot Menu FvFile(86488440-41bb-42c7-93ac-450fbf7766bf)
Boot0012  Regulatory Information    FvFile(e4a83242-deee-f12e-15ff-0102036cc3ce)
Boot0013  Diagnostic Splash FvFile(a7d8d9a6-6ab0-4aeb-ad9d-163e59a7a380)
Boot0014  OilDiagApp    FvFile(f8397897-e203-4a62-b977-9e7e5d94d91b)
Boot0015* NVMe: SAMSUNG MZALQ512HALU-000L2              PciRoot(0x0)/Pci(0x1d,0x4)/Pci(0x0,0x0)/NVMe(0x1,00-25-38-A4-01-B7-FE-7B)....2.LN........
Boot0016* MSATA Hard Drive: VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f602)
Boot0017* ATA HDD:  VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f601)
Boot0018* ATAPI CD: VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a354)
Boot0019* USB Device: SanDisk Cruzer Snap   PciRoot(0x0)/Pci(0x14,0x0)/USB(3,0)3.!..3.G..A.....
Boot001A* PXE Network Boot: EFI Network (IPv4)  PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/MAC(b4a9fca62a74,0)/IPv4(0.0.0.00.0.0.0,0,0)x.J.+*.N.....=8.
Boot001B* USB CD:   VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,86701296aa5a7848b66cd49dd3ba6a55)

Answer 1

OK I think I improved my understanding of this whole procedure:

UEFI firmware has a NVRAM variable, namely "BootOrder", which defines the order of targets to boot from. There are several types of boot targets. E.g.:

Boot0001* ubuntu    HD(1,GPT,d37539b4-7745-44f3-83b4-59b5ff5dc08f,0x800,0x82000)/File(\EFI\ubuntu\shimx64.efi)

This target specifies the Device Path, the partition, and the file path of the boot loader. In this case it points to the grub on the ESP on my internal drive.

Another type is the Fallback path:

Boot0001* Hard Drive    HD(2,0,00)

This target says "Boot from this disk" - but no further information. What UEFI will do in this case is locate a ESP (The first one it'll find), and boot the /EFI/BOOT/BOOTX64.EFI file.

Once an operating system is installed, it creates a ESP (if one doesn't exist) and installs its own bootloader there. It then adds an entry in the EFI Boot Manager, pointing to the bootloader it just installed.

What happened in my case is as follows: The Linux Ubiquity installed a bootloader (efi grub) on my internal hard-drive, and created an entry in the UEFI Boot Manager as said. The problem is, that grub uses a configuration file grub.cfg which is located on the USB (/boot/grub). So as far as UEFI concerns, it did find a bootloader and passed control to it, so it didn't go on to the next target in line. But grub itself failed since it couldn't find it's configuration file, located on the USB.

A reasonable solution for this is to create a ESP on the USB, use efibootmgr to point the ubuntu entry to boot from there, so when the USB is unplugged, it will naturally go on the line and boot Windows. When it is plugged, it will boot Ubuntu as I was dreaming :)

Thanks to:
@oldfred
UEFI Boot: how does that actually work, then?
The EFI System Partition and the Default Boot Behavior