![](https://infosec.pub/pictrs/image/18f7fca6-a3d6-4bc7-8d63-9fd5d7a11c58.jpeg)
![](https://lemmy.ml/pictrs/image/q98XK4sKtw.png)
Linux bootloaders discover the correct linux volume by UUID (which is in the filesystem), or PARTUUID (which is in the GPT table). It’ll look at every drive, and when it sees the matching one it’ll look in that partition, find the kernel & initrd, suck them into ram, and launch the kernel.
The main problem with moving drives around is - where is the EFI firmware looking for the bootloader in the first place? If you read efibootmgr, the efi data is pretty simple and very much tied to a hardware port. The EFI takes the most preferred bootloader entry, goes to that drive, and runs a file like “\EFI\grub\grubx64.efi”. If that file isn’t right there, the EFI isn’t going to look elsewhere for it.
There is one bootloader name that EFI will pluck out of the blue and (smash the Fx key) offer to you as a boot option - “\EFI\BOOT\BOOTX64.EFI”. Self booting usb installers use that, but you could use it too. Put all the other files that go along with the bootloader in with that boot folder, and rename the appropriate .efi to bootx64.efi.
One thing that I’ve done on odd setups is to put rEFInd on the efi partition as the boot\bootx64.efi loader. It’ll do a pretty fancy job of detecting what’s bootable (may need an additional filesystem_driver.efi), or even chain into grub to finish the startup.
640x480 sounds like the typical fallback if there is no EDID/DDC data and the card is going ahead with the most bare-minimum signal that any screen should accept. Maybe there’s dumb state sitting around in the video card. Maybe, because everything is now so smart that it’s stupid, the monitor itself is the one remembering weird state. Maybe it doesn’t like the text-mode flip or a DPMS command at the end of an update-reboot cycle, so its EDID responder loses the plot. Who the fuck knows what goes on in all this garbage firmware?