Is there anyway to turn secure boot on and remove secure boot keys in the bios and then turn it back off. Not sure if it would make any difference but I usually remove the secure keys and then turn it off. 
Edit: Also is bitlocker turned off or maybe it doesn’t have bitlocker. Depends on the Windows version.
@pebcak
I think the answer lies within this thread. 
I am using an Acer ES1-132. I didn’t have this freezing problems but also problems regarding the detection of my Arch installation as bootable.
I had to copy the .efi-file and rename it to the place and name of the Windows .efi-file. It runs like that since 2017 or so.
Just recently I was stumbleing upon that:
It’s not the first post on the linked page. I refer to the one by Zanna from 03.09.2017 20:23
So maybe try using a different path in your command here.
E.g. \EFI\Linux\BOOTX64.efi instead of \EFI\EnOS\grubx64.efi
I copied my .efi file to (esp)\EFI\Microsoft\Boot\bootmgfw.efi
I haven’t tried the other paths as I did that before I discovered that link from the ubuntu forum.
Just an idea that I wanted to share.
It took me quite long to find that out when I first tried to install Linux on that Laptop. I also don’t understand why some Laptop manufacturer would create such restrictions.
Also: if that should really work, make sure to have a pacman hook to copy the .efi to the place where it needs to be. Otherwise it might happen that you cannot boot after the .efi got replaced through an update. Not hard to repair but annoying.
First try what is already suggested:
It is important to know if this command fails, or not.
There is still the issue of the correct $ESP partition, (p2 in fstab, p6 in installation commands) which can be dealt with in order.
Exactly… could be?
I wonder also if Windows was wiped by creating a new GPT partition and just installing Linux if it works?
At least for me it worked on an Acer ES1-132. But as descriped I had to copy and rename the .efi-file to (esp)\EFI\Microsoft\Boot\bootmgfw.efi
Also at least for my model Acer is just publishing UEFI updates as .exe file for Windows. But there haven’t been updates anyways since 2018 or so.
Right! I asked specifically for /etc/fstab to know which of the ESP:s OP is using…and I still made that mistake.
Anyways,
grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=EnOS --no-nvram
seems to have worked.
The problem starts when writing the EFI boot entry into nvram:
efibootmgr -c -d /dev/sda -p 6 -w -L EnOS -l '\EFI\EnOS\grubx64.efi'
I did not see any confirmation for success from OP.
We can work with this issue.
When/if the bootloader file is successfully created on disk, we can copy it to the default location, copying the file directly.
Actually, OP can try the grub-install command, adding --removable
I did not see any confirmation for success from OP.
it’s fine I wrote it in nr 97… 
I took that as the confirmation for a successful:
Yes, worth trying this as well.
I am sorry, I missed it… 
Well, two things:
--removable`grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=EnOS --no-nvram
where shall --removable go?
As a last resort, how about making a grub-install into /dev/sda2 (Windows ESP) and then run
bcdedit /set {bootmgr} path \EFI\EnOS\grubx64.efi
from a shell from within Windows?
Not sure if this would work or messes up with Windows Boot Manager though.
Anywhere in the command line. It is a parameter. 
If it fails, use The Force ( add also --force ).
grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=EnOS --no-nvram --removable
Installation finished. No error reported
I’m not sure how to do this…
I also did not take it as solved. I know it’s because it does not want to write a specific path but I’m having difficult following what worked.
Reboot. If there is an option to select boot entry, choose the disk (name).
You might want to check entries with efibootmgr -v