The Lenovo forum thread to which you link clearly indicates that the problem is (or at least can be) caused by a faulty cable. Thus, my first suggestion is to follow the advice in that thread and replace the cable, or at least re-seat it. This WikiHow article describes how to replace a SATA hard disk. Just replacing the cable is a subset of that procedure. You can try YouTube, too; I'm sure there are videos on it showing the process.
Beyond that, your setup is a bit weird. You have remnants of an old BIOS-mode GRUB installation on
/dev/sdb; but these remnants probably indicate an installation to a GPT disk, given where the code points on the disk, and
/dev/sdb is currently partitioned using MBR, not GPT. Your
/dev/sdb1 is FAT and holds EFI boot loader files, which means it could be an EFI System Partition (ESP); but it's got the wrong type code for that, and Ubuntu won't normally install to an MBR disk in EFI mode. Your
/dev/sda is a GPT disk, but it has no ESP. My hunch is that this mix of GPT and MBR disks allowed the Ubuntu installer to "slip through the cracks" and set up something that's almost right. Some EFIs may have problems booting from MBR disks -- this feature is not well-tested; it should work, but I'd be shocked if at least some EFIs don't have problems with it. Thus, you may have a "perfect storm" of unusual conditions that's causing you problems.
To correct it, you could try this:
- Back up your important personal data.
/dev/sdb from MBR to GPT, as described in the
gdisk documentation. (I'm the author of
gdisk, which is installed by default on Ubuntu.)
gdisk, change the type code of
/dev/sdb1 to EF00; or using
parted or GParted, add a "boot flag" to the partition.
sudo efibootmgr -c -d /dev/sdb -p 1 -l \\EFI\\ubuntu\\shimx64.efi -L ubuntu. (Note the double backslashes to separate directories in the
-l option.) This should create a new boot entry that will stand a better chance of "sticking" across reboots, since it will now point to a GPT disk.
Note that any partition table changes are potentially risky. The MBR-to-GPT feature in
gdisk is actually surprisingly simple, but it's conceivable that something will go wrong, hence step #1. Don't ignore it.