get_dev_containing_directory.sh

# use e.g. to derive 
# INSTALL_DRIVE
# param for grub-install from the --efi-directory param
# $1 is e.g. /boot/efi
# then this will give you the current boot device

# note: grub-install creates device GUID specific boot config - will stop working when you assign new gpt partition guids


echo /dev/$(lsblk -no pkname $(df -P $1 | awk 'END{print $1}'))

installation using permfunction:

curl -s https://gist.githubusercontent.com/Masterxilo/7d43ff1861617d18db8b6e23be4ec88f/raw/get_dev_containing_directory.sh | sudo permfunction get_dev_containing_directory

using sudo because apparently even on stock ubuntu 18.04 ~/bin is not in PATH...
Now:

get_dev_containing_directory /boot/efi

sudo apt-get install grub-efi grub-efi-amd64
sudo grub-install --no-bootsector --efi-directory=/boot/efi --directory=/usr/lib/grub/x86_64-efi $(get_dev_containing_directory /boot/efi)

Installing for x86_64-efi platform.
Installation finished. No error reported.

if you don't use sudo you get garbage errors:

grub-install: warning: disk does not exist, so falling back to partition device /dev/nvme0n1p6.
grub-install: warning: disk does not exist, so falling back to partition device /dev/nvme0n1p6.
grub-install: warning: disk does not exist, so falling back to partition device /dev/nvme0n1p6.
grub-install: error: disk `hostdisk//dev/nvme0n1p6' not found.

They also have garbage instructions/no focus:

grub-install copies GRUB images into boot/grub.  On some platforms, it may
also install GRUB into the boot sector.

why does it handle more than gpt?

mount -t proc proc proc/
mount -t sysfs sys sys/
mount -o bind /dev dev/