Unable to repair Grub2 - cannot find EFI Directory

[cjlorenz81]

Quick background... running Kali2 on Windows 10 laptop

Windows 10 did an update today 5/26/17 (well maybe a few days ago but rebooted to finish installing today)
Upon reboot the grub boot loader loads up with grub rescue with command prompt. Does not boot past this.

I'm able to go into my bios and select my windows boot loader but unable to boot into Kali since or by using this method.

I attempted to fix the issue but run into an error that the EFI Directory cannot be found.

Below is a copy of everything I've done and now I'm stuck...

root@kali:~# fdisk -l
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 2CAC7E1C-6721-4B3E-83FD-C653B608C319

Device          Start        End    Sectors   Size Type
/dev/sda1        2048     923647     921600   450M Windows recovery environment
/dev/sda2      923648    1128447     204800   100M EFI System
/dev/sda3     1128448    1390591     262144   128M Microsoft reserved
/dev/sda4     1390592 1826659458 1825268867 870.4G Microsoft basic data
/dev/sda5  1826660352 1827690495    1030144   503M Windows recovery environment
/dev/sda6  1827692544 1936979967  109287424  52.1G Linux filesystem
/dev/sda7  1936979968 1953523711   16543744   7.9G Linux swap




Disk /dev/sdb: 29.8 GiB, 32027705344 bytes, 62554112 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xbad74d2f

Device     Boot   Start     End Sectors  Size Id Type
/dev/sdb1  *         64 5456223 5456160  2.6G 17 Hidden HPFS/NTFS
/dev/sdb2       5456224 5457631    1408  704K  1 FAT12


Disk /dev/loop0: 2.4 GiB, 2558234624 bytes, 4996552 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
root@kali:~# sudo mount /dev/sda6 /mnt
root@kali:~# sudo mount --bind /dev /mnt/dev
root@kali:~# sudo mount --bind /proc /mnt/proc
root@kali:~# sudo mount --bind /sys /mnt/sys
root@kali:~# sudo chroot /mnt
root@kali:/# grub-install /dev/sda
Installing for x86_64-efi platform.
grub-install: error: cannot find EFI directory.

System: Sager Laptop - intel core i7-6700HQ
8GB DDR4 RAM
nvidia gtx 950m
intel HD 530
1TB HDD

OS: Windows 10, Kali 2

[_defalt]

Windows 10 doesn't care about dual boot OS. When you update windows 10 it creates a small partition of windows recovery environment for windows reset options. This changes the name of your Linux file system. Now grub remembers the earlier name still pointing to that /dev/sda which is not your linux filesystem anymore so when it boots that partition it doesn't recognize it and launch rescue mode. It's kind of grub fault also because it should recognize partitions with their UUID and not by their serial names. You don't have to re-install grub. The commands you are trying for installing grub are also wrong and don't work for UEFI.

In grub rescue mode enter these commands to update its information about the change in the name of your linux filesystem:
set root=(hd0,gpt6)
set prefix=(hd0,gpt6)/boot/grub
insmod normal
normal

After booting into kali enter this command in terminal:
sudo update-grub
sudo grub-install /dev/sda

[cjlorenz81]

Windows 10 doesn't care about dual boot OS. When you update windows 10 it creates a small partition of windows recovery environment for windows reset options. This changes the name of your Linux file system. Now grub remembers the earlier name still pointing to that /dev/sda which is not your linux filesystem anymore so when it boots that partition it doesn't recognize it and launch rescue mode. It's kind of grub fault also because it should recognize partitions with their UUID and not by their serial names. You don't have to re-install grub. The commands you are trying for installing grub are also wrong and don't work for UEFI.

In grub rescue mode enter these commands to update its information about the change in the name of your linux filesystem:
set root=(hd0,gpt6)
set prefix=(hd0,gpt6)/boot/grub
insmod normal
normal

After booting into kali enter this command in terminal:
sudo update-grub
sudo grub-install /dev/sda

_defalt - Thanks for the reply. While waiting for some assistance a friend of mine kind of sort of fixed the issue for me at work. We booted to my Kali live usb in failsafe mode (since thats the only way I can get that to load up.. for some reason)
He repaired it using the above but also mnt'd the

 sudo mount /mnt/boot/efi

However now the Windows installation mount point is missing from Grub when it loads.

So now my question is.. Am I able to still fix this using your method or is there another way to fix this? I can still boot into windows by choosing the Windows bootloader through the Bios but that's a bit clumsy.
Any and all help is appreciated in this matter...

[_defalt]

My solution was for if you try to boot kali and it ends with grub rescue mode. If you manage to boot kali by reinstalling grub but you couldn't find Windows entry in it then it is a different issue. Generally this happens if you use Legacy BIOS for kali and UEFI for Windows 10.

If you boot both in UEFI mode then simply entering these commands will add windows entry in grub:
sudo update-grub
sudo grub-install /dev/sda

[cjlorenz81]

My solution was for if you try to boot kali and it ends with grub rescue mode. If you manage to boot kali by reinstalling grub but you couldn't find Windows entry in it then it is a different issue. Generally this happens if you use Legacy BIOS for kali and UEFI for Windows 10.

If you boot both in UEFI mode then simply entering these commands will add windows entry in grub:
sudo update-grub
sudo grub-install /dev/sda

_defalt - Thanks for all the help. That resolved my issue. Now I can get back to my freelance work. It's sad that I understand somethings but fixing grub was not one of them...