Linux GRUB – Fix GRUB After Moving Root Partition

The kernal does not see the changes as you are partitioning your boot drive...

This is because you could have removed the partition that contains your kernel.

You need to reboot or run partprobe.

You're seeing a bug, and it's almost certainly not related to Secure Boot. I have several suggestions, but none is guaranteed to fix the problem:

• Update your firmware -- If the bug is in the firmware, updating it may fix the problem. Check with the computer's (or motherboard's) manufacturer to find updates. (They're probably called "BIOS updates," although technically your firmware is not a BIOS.) After the update, reboot into Linux and try again.
• Reset your firmware to its default settings -- Sometimes EFI boot manager lists become corrupted, causing symptoms like those you describe. Resetting all the firmware settings to their defaults in the setup utility may fix this problem. Unfortunately, this step will remove any working boot manager entries, so you may need to use an emergency tool (such as my rEFInd boot manager on a USB drive or CD-R) to boot until you re-create your working entries.
• Delete unused boot manager entries -- Deleting unused boot manager entries (with the -B option to efibootmgr) can also work around corrupted entries. Try efibootmgr alone, or efibootmgr -v for more verbose output, to locate duplicate or unwanted entries. (Note that the firmware may re-create some automatically when you reboot. This may happen with network boot options or options to boot external media, for instance.)
• Use another tool to create the boot entry -- Sometimes efibootmgr doesn't work but a tool in another OS (like bcdedit or EasyUEFI in Windows) or the bcfg tool in an EFI shell will get the job done. Thus, you might try these tools instead of efibootmgr.
• Use a fallback filename -- The fallback filename (EFI/BOOT/bootx64.efi on x86-64 systems) can be used if nothing else is working; however, this filename will typically be the last one a computer tries to boot. Thus, if it's already booting via some other name (like the Windows boot loader, EFI/Microsoft/Boot/bootmgfw.efi), you may need to back that up, rename your desired boot manager/loader to the currently-booting default, and reconfigure the new boot loader to offer to boot the one it's masquerading as using its new name. This is a bit of a juggling act at best, and not all EFI boot loaders for Linux can chainload to another EFI program, so it may not work properly. (I don't recall offhand if SYSLINUX can chainload another EFI program.)
• Switch to BIOS/CSM/legacy booting -- Most EFIs provide a Compatibility Support Module (CSM), which enables them to boot BIOS-mode boot loaders. Thus, you can install a BIOS-mode boot loader for Linux, activate the CSM, and boot in this way. If you're dual-booting another OS, though, you'll need to install its BIOS-mode boot loader, too, and this may necessitate changing from GPT to MBR partitioning. Overall, this approach is likely to be a bit of a pain; but on some EFIs (mostly old ones from 2011 or thereabouts), it may be the best approach.
• Return the computer for a refund -- If all else fails, and if the computer is within its store return period, you can return it for one that works. In fact, I recommend this approach before either of the preceding two options, if possible. If you do this, be sure to contact the manufacturer to tell them why you returned the computer. EFIs have had serious bugs from Day One, and some manufacturers have been slow to fix them, in part because their customers never complain, so the manufacturers don't realize how serious the bugs are.