That’s alright, I’ll do my best to walk you through it.

Your drive contains multiple partitions (/dev/sda1 through /dev/sda3).
One of these drives is going to be your EFI partition. This is what your system can read before linux boots, your BIOS can’t understand ext4 / btrfs / etc, but it can understand fat32.
If you run lsblk -no FSTYPE /dev/sda1 it should return vfat if that’s your EFI partition. That’s what we’re going to mount to /mnt/boot/efi

I’m assuming that /dev/sda3 is your data partition, e.g. where your linux install is. You can find the filesystem format the same way as your EFI partition. Edit: After determining which partition is which, you’re going to want to mount the root partition, and then the EFI partition
mount /dev/sda3 /mnt
mount /dev/sda1 /mnt/boot/efi

Unix systems have theology of “everything is a file”, all devices and system interfaces are mounted as files. As such, to be able to properly chroot into an offline install, we need to make binds from our running system to the offline system. That’s what’s achieved by running for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
This is just a simple loop that mounts /dev, /dev/pts, /proc, /sys, and /run to your offline install. You’re going to want to either add /sys/firmware/efi/efivars to that list, or mount it (with -B, which is shorthand for --bind, not a normal mount).

Once you’ve done this, you should be able to successfully chroot into /mnt (or /mnt/root if running btrfs)
At this point, you should be able to run your grub repair commands.