Dell G3 15 3579 System BootOrder not found

Ok so I can only make assumptions looking from the result. I did find a solution but the reason why only this worked, I am not entirely sure.

I found the solution at https://askubuntu.com/a/749414/908310 and particularly the part:

Manual install of GRUB to the fallback filename on the external disk -- OS installers boot by using a fallback filename of EFI/BOOT/bootx64.efi. 
If you copy Shim (which launches GRUB) to this filename (by copying EFI/ubuntu to EFI/BOOT on the ESP and then renaming shimx64.efi to bootx64.efi 
in EFI/BOOT), your firmware will be able to launch your USB-based GRUB just as it did the Ubuntu installer. This will work past both of the problems 
I've just identified, but you'll need to use the computer's built-in boot manager to select which OS to boot. This built-in boot manager ranges from 
unusable to tolerable, so this might or might not be an acceptable solution. You may also need to tweak your boot order after you install Ubuntu to 
keep it from launching GRUB from either the internal disk's ESP or the external disk's ESP by default.

So, what I think(feel free to correct me) is the issue is that I tried to install Ubuntu in the M.2 NVMe drive while having an HDD (SSD) installed. The port where the SSD is installed is considered as the primary drive. The primary drive also had the Windows 10 on it. I think that this somehow messed up the boot sequences resulting all automation software, like boot-repair and rEFInd.

I think that there is also a minor issue detecting the NVMe. So the problem might be a combination of a UEFI that is not completely working fine, and the fact that the SSD is considered the primary HDD.

All of the above with the respect to all the settings managing the boot priority of course.

Also, the SSD seem to be loading the Windows boot loader but in the disk, the (hd0,1) there is a partition related to the grub loader. Which makes me assume that the boot-repair and rEFInd software used the primary disk as a source but the primary disk already had the windows boot loader to begin with.

So what I did is that while being logged in in Ubuntu, I did the following:

$ sudo su
# cd /boot/efi/EFI
# mv BOOT BOOT_bak
# cp -R ubuntu BOOT
# cd BOOT
# mv shimx64.efi bootx64.efi

The above basically mean that I copied over the bootloader used normally to boot grub from the folder ubuntu and placed it instead of the one used by default by ubuntu.

From the post linked in askUbuntu, the following piece seems to explain the whole thing above:

To boot an internal disk in EFI mode, the OS typically stores a boot loader as a file on the EFI System Partition (ESP) on the disk. 
This filename can be anything legal, but for Ubuntu it will be EFI/ubuntu/shimx64.efi, 
which in turn launches EFI/ubuntu/grubx64.efi.

If we assume that in the end, grubx64 is the one that is fired, this file did not exist in the original BOOT folder. Thus, the error could occur. On the other hand, by allowing the system to automatically create an "ubuntu" boot entry, it probably did not detect automatically which hdd to fire and thus lead us to the grub screen.

Now, probably, at most 50% of my assumptions are true. However, this was a solution that worked for me.

After running the above commands, and copying the ubuntu folder over to BOOT, I was able to delete the ubuntu boot entry, set the priority to the NVMe EVO970 and have it load the grub loader, from where I can boot into both ubuntu and Windows, without having an issue or having the ubuntu entry re-created.

I hope the above can help someone else in the future.

In general, trying to install ubuntu 18.04 in this laptop, lead me to face 3 issues:

• The Samsung NVMe 970 was not being detected (AHCI sata drive mode).
• Linux where freezing upon suspend or randomly (the nouveaux drivers solved by nouveaux.modeset=0)
• The startup issue described in this post.

Now everything works as a charm :)