What is the least painful way to fix my stupid boot setup?

Question

I had a 750GB hard drive (/dev/sda1) that I replaced with a 1TB SSD (/dev/sdb1). I wanted to then erase the old HDD and use it as a backup drive. However, it seems that the boot partition is still on the old drive, and grub finds no boot on the new drive. This creates a few problems:

1. The default OS at grub is then Ubuntu 16.04 on the HDD, instead of Ubuntu 18.04 on the new drive. If I am not there to pick which OS, it goes to the old one, which is not really functional.

2. I cannot erase the old HDD until I have a proper boot on the new SSD.

3. I recently installed HWE on Ubuntu 18.04, so that I can use the 5.0 kernel, however it doesn't seem to use or recognize that kernel. I suspect that this is also grub related, so it seems best to fix grub first.

What is the least painful way to do this? I am guessing that I need to boot in from a live CD, modify the partition on my SSD, and install a bootloader somehow. Can anyone point me to some instructions on how to do this without screwing up my OS or home directory?

This post looks similar, but scared me a bit: Remove second hard drive OS from grub

Details of my system:

~$ uname -a
Linux xxxxx 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 16:00:05 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.3 LTS
Release:        18.04
Codename:       bionic

Results of sudo parted -l :

Model: ATA WDC WD7500BPKT-0 (scsi)
Disk /dev/sda: 750GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type      File system     Flags
 1      1049kB  50.0GB  50.0GB  primary   ext4            boot
 2      50.0GB  750GB   700GB   extended
 5      50.0GB  66.0GB  16.0GB  logical   linux-swap(v1)
 6      66.0GB  750GB   684GB   logical   ext4

Model: ATA Samsung SSD 840 (scsi)
Disk /dev/sdb: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system     Name  Flags
 1      1049kB  1000MB  999MB   fat32                 boot, esp
 2      1000MB  17.0GB  16.0GB  linux-swap(v1)
 3      17.0GB  67.0GB  50.0GB  ext4
 4      67.0GB  1000GB  933GB   ext4

Error: /dev/sdc: unrecognised disk label
Model: Initio INIC-1610P (scsi)                                           
Disk /dev/sdc: 4142MB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags: 

Model: Linux device-mapper (crypt) (dm)
Disk /dev/mapper/cryptswap1: 16.0GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags: 

Number  Start  End     Size    File system     Flags
 1      0.00B  16.0GB  16.0GB  linux-swap(v1)

Answer 1

The new install to SDD was in UEFI mode, so your machine is UEFI capable -- I'd suggest you keep the UEFI mode. A quick note to a question of yours: You should be able to run sudo update-grub from the 16.04 system and pick up the 5.0 kernels on the 18.04 to try. The UEFI installer has a bug 1396379 which puts the UEFI bootloaders onto sda, regardless of which device you specify, so probably the SDD EFI partition is empty. The legacy 16.04 install probably does not have these UEFI bootloaders, so you will have to copy them off the install media, basically just copy all the files from the install media's /EFI/BOOT/ directory to EFI/BOOT directory on the EFI partition. If the EFI partition has a filesystem, you should be able to mount it:

sudo mount -tvfat /dev/sdb1 /tmp/xx

If no filesystem even exists, make one first, then mount it:

sudo mkfs.vfat /dev/sdb1

Then just copy the files over(bootx64.efi, grubx64.efi, ... etc.) The EFI will also need a stub grub.cfg file which includes the maintained grub.cfg file from your root filesystem. Get the UUID for your root:
sudo blkid then edit that UUID into the below file (EFI/ubuntu/grub.cfg)

search.fs_uuid your-UUID root hd1,gpt1 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg  

That should produce a bootable UEFI setup on sdb -- select it as a boot device and see if it boots.

---

Your EFI/BOOT directory does not contain a copy of grubx64.efi, so the bootx64.efi there must be grubx64.efi (check their sizes to confirm). This should work when secure boot is disabled. If you want to allow secure boot, you put grubx64.efi and shimx64.efi there, with shimx64.efi renamed to bootx64.efi.