Thanks I did find it in that convert guide.
The first thing is to ensure that your efi partition is large enough. Run the command
du -sh /bootand compare that to the size of your EFI partition. Your EFI partition needs to be larger than the output of the command. If it is, you can continue. If not, you need to enlarge the partition before going any further.
Will just stick to 1G. Will reboot and see what happens with gparted 
This is all what Linux is about from my point of view.
I have distrohopped like crazy during 2021, on average installing and reinstalling too many distros every couple of days till I settled on EndeavourOS.
Even after being settled I did a few fresh installs of EndeavourOS, on the same machine and on 2 old laptops, just trying, learning and breaking my system with my own hands out of curiosity (sometimes because at the beginning I didnāt know how to manage my way in EndeavourOS, so a fresh install was easier and faster for me than fixing)!
But now, it is almost a year on one install! I canāt believe I did that. Since 2000 on Linux and I had to do an install every time a new release comes out)
Exactly. Sorry! While writing the post I copied the link and just forgot to paste it! 
how do you tried the third command? from a usb stick?
Maybe Fedora does something to be sure Grub wonāt break the system or it just happened.
You will find several threads about this Grub issue.
My problem with it, that I might be not focusing properly to reinstall Grub if required, maybe I am tired, sleepy, .. or whatever which will result in a nonbootable system!
So, why take the risk if I have a bootloader that just works no matter what and same time I donāt really need the extra features that Grub offers and I could boot faster!
This one: sudo grub-install --efi-directory=/boot/efi ?
Yes. I arch-chrooted into the system from the live usb.
It worked in my case but not for @gipo355:
Yes, the main point is I do not have to worry about not being able to boot in case I did not focus and do the work properly.
The install log may provide some hints about the correct grub-install parameters.
The log is in /var/log, either Calamares.log or endeavour-install.log.
Just search for grub-install.
Note also that if you have changed something like your partitions etc. after the install, the info may not be fully correct.
sudo grep grub-install [Ce]*.log
nothing worked, os reinstalled with the last iso
less than 1 hour to complete all and having /home separated than / itās wonderful for this case
I guess GRUB will stay in my IgnorePkg list for the foreseeable future then.
Itās a bit odd that only some users seem to have been hit by this issue.
Also strange that the grub-install worked for me and not others.
Glad anyways you got system up and running again!
With the latest updated grub package today do you actually have to reinstall grub? Or just run the update?
Edit:
[ricklinux@eos-plasma ~]$ grub-install
Installing for x86_64-efi platform.
grub-install: warning: disk does not exist, so falling back to partition device /dev/nvme0n1p1.
grub-install: warning: disk does not exist, so falling back to partition device /dev/nvme0n1p1.
grub-install: warning: disk does not exist, so falling back to partition device /dev/nvme0n1p1.
grub-install: error: disk `hostdisk//dev/nvme0n1p1' not found.
[ricklinux@eos-plasma ~]$
Edit: Do i have to use sudo? Or is it another issue?
I do always grub-install --no-nvram and regenerate grub.cfg after each update to the package grub.
After reboot, I had the same issue as described in OP.
I tried grub-install --efi-directory=/boot/efi. This seems to have resolved the issue for me.
Judging by what others have posted, this may not work for all. And not all seem to be hit by this issue either.
Iām also on btrfs so Iām not sure?
I did it this way?
[ricklinux@eos-plasma ~]$ sudo grub-install /dev/nvme0n1p1
[sudo] password for ricklinux:
Installing for x86_64-efi platform.
Installation finished. No error reported.
[ricklinux@eos-plasma ~]$
Not sure if thatās how you are supposed to do it? Then run update grub command?
Iām on BTRFS too, this morning I updated the system, GRUB included, after the update I ran the following:
sudo grub-install --no-nvram
sudo grub-mkconfig -o /boot/grub/grub.cfg
Restarted the system and got greeted by this error message:
error: symbol `grub_is_shim_lock_enabled` not found
Tried to Google the error and couldnāt find any reference to it, so I resorted to chroot and downgrade. So if you attempt this upgrade keep a live USB close by cos you might need it. You could try to run the command:
sudo grub-install --efi-directory=/boot/efi
Followed by:
sudo grub-mkconfig -o /boot/grub/grub.cfg
But so far itās kinda hit or miss. For the time being I would just refrain from upgrading GRUB if possible, I personally added it to IgnorePkg list inside /etc/pacman.conf after I downgraded to the previous version and Iāll probably keep it like this for a couple of days, just to check if other solutions emerge or if someone else reports this problem on Arch.
It looks like this version of GRUB introduced some fixes for Secure Boot and shim lock (the error message) seems to have something to do with Secure Boot, but thereās no documentation whatsoever about this error message, at least I couldnāt find any.
Iām seriously thinking about switching to Systemd-boot, but I kinda like GRUB for its BTRFS support, so weāll see.
It worked for me using this format on all 5 of my systems. Some with btrfs and others just ext4. Some dual boot Win 11 others just EndeavourOS. All with grub.
sudo grub-install /dev/nvme0n1p1
sudo grub-mkconfig -o /boot/grub/grub.cfg
Just tried using the grub-install --efi-directory=/boot/efi and bricked again, Iām just gonna freeze GRUB indefinitely at this pointā¦
yeah i donāt really think we understood what it is because for some itās working and for others no. I just put grub in IgnorePkg too
Happened to me, too. Switched to SystemD boot for the time being.