Ok, so several issues here. Basically trying to get Ubuntu to actually boot on a RPi 4B combined with the new NVMe version of the Argon M.2 adapter is absurd and basically does not work right until you spend about 15 hours or more going through all sorts of things until finally finding a workaround. Which we were finally able to figure out.
Wanted to share in case it helps.
So this isn’t too bad if you do basic things like attach a 2 TB or smaller drive and just use MBR. It works, you can boot from it. Can install Ubuntu or something else. Just works. Raspberry Pi does not really use an actual BIOS though so if you want to actually boot from something other than MBR, you have to do several things to it that makes it not want to boot up. Plus so many forum posts are just wrong because of changes over the last few years that let you boot from USB now.
Start by updating the EEPROM (rpi-eeprom-config, probably on the micro SD card) then USE THE x64 VERSION OF YOUR OS. Then created a new modified hybrid partition.
https://forums.raspberrypi.com/viewtopic.php?f=29&t=196778
Used some of this tool (really just scripts) to create a basically modified “backwards friendly” GPT that supported booting into a FAT32 that the RPi needs to boot and then also mostly be an almost 4 TB EXT4 partition. More mbr2gpt than usb-boot and also some gparted.
The 3 files you need to modify are:
File Number 1
FAT32 boot partition
/boot/cmdline.txt
You will be pointing this towards the PARTUUID of the EXT4 drive. Not the MBR. CHANGE THE PARTUUID to match your actual PARTUUID. You can get that by using blkid. Note that the PARTUUID and the UUID will differ. Don’t use quotes around the actual series of characters either.
console=serial0,115200 dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbc rootfstype=ext4 rw rootwait fsck.repair=yes fixrtc quiet splash
File Number 2
FAT32 boot partition
/boot/config.txt
This one is a bit more complicated.
[all]
kernel=vmlinuz
cmdline=cmdline.txt
initramfs initrd.img followkernel
# Config settings specific to arm64
arm_64bit=1
dtoverlay=dwc2
File Number 3
EXT4 main partition
/etc/fstab
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
#/dev/sda1 UUID=AAAA-BBBB LABEL=boot
PARTUUID=bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb /boot vfat defaults 0 2
#/dev/sda2 UUID=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa LABEL=rootfs
PARTUUID=bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbc / ext4 defaults,noatime 0 1
#/dev/sda3 UUID=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaab LABEL=4TB
PARTUUID=bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbd /4TB ext4 rw,noatime 0 2
Make sure you copy over the CORRECT /boot files (you can copy over from the boot disk that works, just make sure you use the correct x64 one that is made for the RPi).
The # lines just show you and help you keep track of things and are not used. Put the PARTUUID on a separate line and do not comment it out with the # character.
Make sure you use PARTUUID and not UUID.
Set partition flags of /dev/sda1 (labeled as /boot) to boot, legacy_boot and esp but not sure if all of those are needed.
Once that is all done, then you STILL need to do two things. The first one is a bit odd but don’t really put anything else into the other USB 3.0 port. It both seems to make it not reboot but hang but also block it from actually booting from the USB 3.0 NVMe drive.
After that, were also having issues when a basic USB hub was plugged in. Or a second drive even if it had no actual GPT or MBR. It would just cause MSD LUN 0 timeout or MSD error 2 but that’s better than GPT: No bootable partitions or Trying partition: 0 endlessly.
So, somewhat oddly, changed the eeprom file. sudo rpi-eeprom-config --edit and then changed BOOT_ORDER=0xf1444 to give it three tries to boot to the USB in this case (it starts on the right side due to it’s ENDIAN status). Also lowered the USB_MSD_DISCOVER_TIMEOUT=5000 because if it doesn’t find it, quit waiting around for thirty seconds each time.
So this should fail to boot the first time then boot the second time. Unless you plug something into the other USB 3.0 port which might make it not boot up the third time either. But then if you do a soft reboot, it will load the USB OS then.
There is probably some kind of bug there unless we did something wrong with the boot firmware.
Hope this is helpful and took way longer than it should have to just let the RPi boot from a 4 TB NVMe SSD but it actually does work now.