Well, it’s really look like a bug for me too but I still must read the installation script before any conclusion.
My desktop machine was my test bench, but about six months ago one of my hard drives died and I needed the other one to backup other things, and this year I’m planning to upgrade my machine entirely, at this moment, I don’t have resources to test and debug, but AFAIR I used the commands below to fix my grub after failed to install on a secondary disk during many fresh test installations.
sudo mount /dev/sdXY /mnt/root/
sudo mount /dev/sdXY /mnt/root/boot/
sudo mount --bind /proc /mnt/root/proc
sudo mount --bind /dev /mnt/root/dev
sudo mount --bind /sys /mnt/root/sys
sudo chroot /mnt/root
sudo grub-install /dev/sdX
sudo grub-mkconfig -o /boot/grub/grub.cfg
Anyway, there is no difference between supposedly universal connections like SATA mean to be, since that, GRUB doesn’t juggle disks because once generated UUID must be the same until reset partition or give a command to set new one to the disk. It’s very strange disks become inaccessible after grub update.
For who uses GPT partitions and need to check UUIDs the command below may be helpful
For non GPT
On another similar situation that I had, I think 3 years old now, my UEFI/BIOS saved data got corrupted and gave me some strange bugs like that, after bios reset and reconfiguration the data still got corrupted, then I flashed with last update and reconfigured and voilá, the problem disappeared. I don’t know why happened but happened
Also my SSD (which died 6 months ago) got an intermittent problem in the first sector became unwritable and unable to install any bootloader giving me similar headache, the funny thing is that SSD lived another year after this happened, I suppose that was because the old hardware architecture and flawed firmware.