I think @wind77 might have a point!
I recently ran into a similar problem. In the end the solution was as easy as to get into the UEFI boot menu and select the proper start device.
So it might be worth to double check what drive/OS is set as the boot drive
IMHO, your system actually booted up properly, it just had problems loading your GFX card drivers before showing the GUI login screen.
That’s why @dmt suggest you to make your boot more verbose on screen:
I think you are familiar with this articles?
I think the UEFI is playing important role here. Some like many ESPs, some not. Some generate the menu “independantly” from the found .efi files, some not. Some read all the drives i guess, some would probably generate a menu for only the active drive. I am pretty sure there are also differences in what happens as man reinstalls grub and how the UEFI interprets is and generates menu. It is worth looking there - bootorder, etc. And BTW the first post - that was a veeery slim EFI boot menu. I didn`t see anything about recovery, PXE, USB boot, so obviously THIS UEFI has some other options and does not put everything automatically in the menu like mine for example. So it might as well generate menu only on the currently selected drive as 1st in bootorder. Just an assumption, but worth checking.
I can give example with my current system:
For example, i had ubuntu, at some point i deleted the partition. Then i installed manjaro. The ubuntu .efi did not appear in the grub menu, but was still there in my EFI boot menu. I deleted it with efibootmgr command… and it reappeared at reboot. Turned out i had to mount the ESP and delete the ubuntu folder/.efi. After that it disappeared automatically without me touching the EFI variables with efibootmgr.
Later, i decided i want to separate windows and its recoveries from my manjaro, in case the first decides to mess with the ESP1 on update. I made another ESP2 (vfat, setting boot and esp flags from gparted live). Then i reinstalled grub there following the exact same tutorial i posted earlier. It put the manjaro grub .efi file on the ESP2 and bumped the EFI variables (then i edited the fstab to change the efi entry UUID but it looks right in your case). Right now, if i use efibootmgr, i see the menu lists only the NEW .efi file on ESP2, although i did not bother to delete the same manjaro grub on the ESP1.
So you see, a lot of things can vary between UEFI/firmware manufacturers and updates.
[teo@teo-lenovo-v15 ~]$ efibootmgr
BootCurrent: 0004
Timeout: 0 seconds
BootOrder: 0004,0006,2002,2001,2003
Boot0001* EFI PXE 0 for IPv4 (6C-24-08-95-B3-FF) PciRoot(0x0)/Pci(0x1c,0x0)/Pci(0x0,0x0)/MAC(6c240895b3ff,0)/IPv4(0.0.0.00.0.0.0,0,0)RC
Boot0002* EFI PXE 0 for IPv6 (6C-24-08-95-B3-FF) PciRoot(0x0)/Pci(0x1c,0x0)/Pci(0x0,0x0)/MAC(6c240895b3ff,0)/IPv6([::]:<->[::]:,0,0)RC
Boot0004* manjaro HD(7,GPT,dfb81846-a72a-4628-9111-00a5296a6ad5,0xcf07000,0x64000)/File(\EFI\manjaro\grubx64.efi)
Boot0006* Windows Boot Manager HD(1,GPT,1dd5ce08-d717-4a17-b7d5-80fb51413d7d,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330034003400640034003700390035007d00000029000100000010000000040000007fff0400
Boot2001* EFI USB Device RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network RC
[teo@teo-lenovo-v15 ~]$ sudo ls -l /boot/efi/EFI/manjaro
total 140
-rwx------ 1 root root 143360 24. Jun 23:17 grubx64.efi
you cant have two flags boot on the same disk
you have 3 boot/efi
Sorry for the late reply.
Spot on! I disconnected all drives, except the new NVMe and did what you told me (except that the file is located in /etc/default/grub, in case somebody else needs this) and I got more information:
I think that’s exactly right. The internet tells me that this is indeed most probably related to either the DM or the graphics card driver. While I’m confident that I can weed that out by myself, helpful tips are of course welcome. Especially, since I’m still a little concerned that I might screw something up. The main reason being that the system does work, as long as I boot with a different GRUB. So the driver and the DM should be fine, correct?
Side note: What confuses me a little, but might be unrelated, is the fact that even with sda disconnected, I’m still offered the Windows Boot Manager in the boot selection of my motherboard. 
Here you go:
sudo parted -l
[sudo] password for ******:
Model: ATA Crucial_CT250MX2 (scsi)
Disk /dev/sda: 250GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 524MB 523MB ntfs msftdata
2 524MB 629MB 105MB fat32 EFI System Partition boot, esp
3 629MB 250GB 249GB ntfs msftdata
Model: ATA Samsung SSD 860 (scsi)
Disk /dev/sdb: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
2 1049kB 629MB 628MB fat32 boot, esp
1 629MB 500GB 499GB ext4
Model: ATA ST4000DM005-2DP1 (scsi)
Disk /dev/sdc: 4001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 17,4kB 134MB 134MB Microsoft reserved partition msftres
2 135MB 3372GB 3372GB ntfs Basic data partition msftdata
3 3372GB 4001GB 629GB ext4
Model: Samsung SSD 960 EVO 1TB (nvme)
Disk /dev/nvme0n1: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 1000GB 1000GB ntfs Spiele2 msftdata
Model: Samsung SSD 970 EVO Plus 2TB (nvme)
Disk /dev/nvme1n1: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 629MB 1999GB 1998GB ext4
2 1999GB 1999GB 628MB fat32 boot, esp
While you are right, IMHO, this does not explain, why the system won’t boot with just nvme1n1 connected. I think that’s indeed related to the DM or the graphics driver and as soon as I have solved this problem, I can remove sdb and format sda2, so that I only have one boot/esp.
EDIT: While stuck at the screen shown above, I couldn’t switch to TTY. I’ll advance by following the following HowTo (and the fixes linked in the HowTo):
Oops, can’t believe I missed that typo, fixed.
What are the infos of nvme1n1p2
(Partition type GUID etc)
lsblk -o PARTTYPE,PARTTYPENAME,PARTUUID /dev/nvme1n1p2
The first number printed should be equal to c12a7328-f81f-11d2-ba4b-00a0c93ec93b see: EFI system partition - ArchWiki and the specs…
Plus a recursive verbose listing of that partitions contents might help also…
Example output of mine:
PARTTYPE PARTTYPENAME PARTUUID
c12a7328-f81f-11d2-ba4b-00a0c93ec93b EFI System ????????-????-????-????-????????????
Good news: I didn’t mess up my system. 
Bad news: I spend the last 2 hours trying to fix the problem, with no real progress. Here is what I did:
3 to the linux line in the GRUB editor. The boot went a little further:
acpi=off,nolapic,nomodeset,nvidia.modeset=0 to the linux line in the GRUB editor. Once again, the boot went a little further:Since I ran out of options, I chrooted again and tried the following things:
mhwd. This allowed me to boot further, but I received an error Failed to start load kernel modules. journalctl -xb was inconclusive (at least to me).What I really don’t get: If there was a problem with the drivers or the DM, then why does the system boot at all?
Here you go:
lsblk -o PARTTYPE,PARTTYPENAME,PARTUUID /dev/nvme1n1p2
PARTTYPE PARTTYPENAME PARTUUID
c12a7328-f81f-11d2-ba4b-00a0c93ec93b EFI System ????????-????-????-????-????????????
Or do you actually need the PARTUUID? I just censored it, because you did. 
Well it could help to see if your UEFI-Menu entry points to the correct one, when checking with efibootmgr -v 
ls --recursive /boot/efi
/boot/efi:
EFI
/boot/efi/EFI:
manjaro
/boot/efi/EFI/manjaro:
grubx64.efi
lsblk -o PARTTYPE,PARTTYPENAME,PARTUUID /dev/nvme1n1p2
PARTTYPE PARTTYPENAME PARTUUID
c12a7328-f81f-11d2-ba4b-00a0c93ec93b EFI System 9c967a2c-739f-47fb-aeb1-ff618a6e73e6
efibootmgr -v
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0000,0002
Boot0000* Windows Boot Manager HD(2,GPT,e3a5c15d-03d8-43a8-85ab-2004c68c621a,0xfa000,0x32000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330034003400640034003700390035007d0000000e000100000010000000040000007fff0400
dp: 04 01 2a 00 02 00 00 00 00 a0 0f 00 00 00 00 00 00 20 03 00 00 00 00 00 5d c1 a5 e3 d8 03 a8 43 85 ab 20 04 c6 8c 62 1a 02 02 / 04 04 46 00 5c 00 45 00 46 00 49 00 5c 00 4d 00 49 00 43 00 52 00 4f 00 53 00 4f 00 46 00 54 00 5c 00 42 00 4f 00 4f 00 54 00 5c 00 42 00 4f 00 4f 00 54 00 4d 00 47 00 46 00 57 00 2e 00 45 00 46 00 49 00 00 00 / 7f ff 04 00
data: 57 49 4e 44 4f 57 53 00 01 00 00 00 88 00 00 00 78 00 00 00 42 00 43 00 44 00 4f 00 42 00 4a 00 45 00 43 00 54 00 3d 00 7b 00 39 00 64 00 65 00 61 00 38 00 36 00 32 00 63 00 2d 00 35 00 63 00 64 00 64 00 2d 00 34 00 65 00 37 00 30 00 2d 00 61 00 63 00 63 00 31 00 2d 00 66 00 33 00 32 00 62 00 33 00 34 00 34 00 64 00 34 00 37 00 39 00 35 00 7d 00 00 00 0e 00 01 00 00 00 10 00 00 00 04 00 00 00 7f ff 04 00
Boot0001* manjaro HD(2,GPT,9c967a2c-739f-47fb-aeb1-ff618a6e73e6,0xe8a82840,0x12b800)/File(\EFI\manjaro\grubx64.efi)
dp: 04 01 2a 00 02 00 00 00 40 28 a8 e8 00 00 00 00 00 b8 12 00 00 00 00 00 2c 7a 96 9c 9f 73 fb 47 ae b1 ff 61 8a 6e 73 e6 02 02 / 04 04 36 00 5c 00 45 00 46 00 49 00 5c 00 6d 00 61 00 6e 00 6a 00 61 00 72 00 6f 00 5c 00 67 00 72 00 75 00 62 00 78 00 36 00 34 00 2e 00 65 00 66 00 69 00 00 00 / 7f ff 04 00
Boot0002* UEFI: SanDisk Extreme 0001 PciRoot(0x0)/Pci(0x14,0x0)/USB(24,0)/CDROM(1,0x5354d8,0x8000)0000424f
dp: 02 01 0c 00 d0 41 03 0a 00 00 00 00 / 01 01 06 00 00 14 / 03 05 06 00 18 00 / 04 02 18 00 01 00 00 00 d8 54 53 00 00 00 00 00 00 80 00 00 00 00 00 00 / 7f ff 04 00
data: 00 00 42 4f
I’m afraid this might be a stupid question, but isn’t it weird, that lsblk -f tells me that the mounted boot partition is on nvme1n1p2?
...
nvme1n1
├─nvme1n1p1
│ ext4 1.0 9c57c860-5b10-48bb-b317-03bed2a111b7 1,1T 34% /var/lib/snapd/snap
│ /
└─nvme1n1p2
vfat FAT32 F8AF-BD3B 597,7M 0% /boot/efi
...
You are actually already booted with it-it seems?
Are you sure that listing is from nvme1n1p2 and not the other SSD?
No not at all because that command lists what the system has mounted where.
FYI: It is the ESP that is mounted not the “boot partition” 
100%, BUT (!) here is the output for sdb2:
lsblk -o PARTTYPE,PARTTYPENAME,PARTUUID /dev/sdb2
PARTTYPE PARTTYPENAME PARTUUID
c12a7328-f81f-11d2-ba4b-00a0c93ec93b EFI System 9c967a2c-739f-47fb-aeb1-ff618a6e73e6
And the PARTUUIDs are identical (probably a result of the cloning). Might that be part of the problem?
Anyhow, as far as i can tell your system is already booted using the grubx64.efi from your nvme1n1p2, so from the UEFI point of view its all working as intended…
If you have problems after grub starts your system, then it’s further down the rabbit hole
OMG 
OFCOURSE thats the problem, you can’t have duplicate UUID’s in a system…
They are per definition meant to be UNIQUE 
That’s what I thought . UUIDs should be unique.
But no worry, there is a way to change the UUID of a partition, i just can’t come-up with it at moment out of head…
Anyhow after you change the PARTUUID of that 2nd partition you want, you need to modify your configs in the UEFI-Menu entry etc to reflect that…
Then it will boot from it no matter if the other drives are connected or not…
Hint: Never ever duplicate a drive without changing ALL UUID’s on it, like Disk, partition etc, if you want to use it in same system as the originals…
Unfortunately, I just recognized that the PARTUUIDs are identical. Thank you for helping me to get to this point. And now that we speak of it, I think I remember that I had to change another UUID (I think it was 352D-5870 to F8AF-BD3B), in order to get the system to boot at all.
I thought it was possible with GParted, but maybe that only changes the short UUID or something.
But I’m not 100% confident, that this will fix the issue, because when I remove sdb, the UUID is unique again, right? And then the system does not boot. So why should it boot after having changed the PARTUUID?
Lets say that the system actually DOES boot, it just doesn’t startup, because your problem is further down the rabbit hole, most likely having todo with Grub, but not your UEFI-BIOS that can’t find your bootloader…
PS:
It’s actually also VERY weird that you dont have a \EFI\BOOT\... directory on that ESP, but i don’t think that really matters with the current situation…