grub2-install: error: cannot find EFI directory

[jddancks]

In the past you have written "gdisk tells me I have an MBR partitioned drive", so I'm a little bit confused now.

owl, I re-installed both windows and CentOS making sure that it used EFI. thats what's confusing you.

And I have been booting into the rescue mode via the CentOS installer this entire time.

I didn't mention that I installed to the disk on another PC because I'm more familiar with that PC's BIOS, which gave me the option to boot both the installer and disk with UEFI as opposed to AHCI, which appears to be only offered by my other PC's BIOS. I figured if AHCI couldn't support UEFI then it would simply refuse to boot. It didn't. Its possible that it is using MBR but anaconda/Windows wrote a backwards compatible MBR which its now reading. But isn't that what a biosboot partition is? In that case I don't understand the error message. I'm looking for a hex editor I can read the 1st sector with, but its definitely not 0s. (I copied the 1st sector to a backup binary file with dd. so I can recover it if I screw up).

No, usually it does not unless you explicit told it to do so. Usually you tell the CentOS installer to mount the existing EFI partition as /boot/efi without overwriting it during installation.

push come to shove I'll try re-installing, and just delete the current CentOS partitions. It didn't appear that I could do that with the Anaconda installer, however

CODE: SELECT ALL
grub2-install /dev/sda
Installing for i386-pc platform.
grub2-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
It seems you haven't booted CentOS rescue in (U)EFI mode. As opposite to MS-Windows the combination BIOS/Legacy/CSM mode and GPT is no problem for CentOS, but an extra "BIOS Boot Partition" is needed here.

However, this is the wrong approach: If MS-Windows is already installed in (U)EFI mode, you should boot the CentOS installation (or rescue) in (U)EFI mode as well.

I will attempt to recover the partition by booting from the other PC and report back

How this will be done differs from computer vendor to vendor. For example Dell lists a proper prepared CentOS USB installation drive twice: One time as "Legacy Boot: USB Storage Device" and one time as "UEFI Boot: Whatever USB stick, Partition 1".

The easiest way to force installation in (U)EFI mode is by tuning Legacy/CSM support if the BIOS/UEFI Setup of your computer off.

Its a Acer computer I bought re-built, so its a no-frills BIOS, I didn't see an option to disable legacy support. I think it only offered "AHCI" or "legacy" boot modes. I'll double check.

And: "grub2-install" is the wrong command on (U)EFI systems anyway. Just make sure the EFI partition is mounted as /boot/efi, (re-)install the package "grub2-efi" and do
CODE: SELECT ALL
grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg

I'm pretty certain grub2-mkconfig reads the config files in /etc/grub.d and creates a new config file. Thats the next step. The first step is the get Centos the default booted OS first. Then I'll go back and add Windows to grub/. Besides, can't I just copy the contents of CentOS created EFI partition for the one I created in Windows and update /etc/fstab?

To confirm that MS-Windows is actually installed in (U)EFI mode it would help to see the output from "fdisk -l" and "gdisk -l /dev/sda".

I'm not gonna copy/paste since I can't, but I can verify its a GPT disk:

Code: Select all

disk label type: gpt

[owl102]

But isn't that what a biosboot partition is?

The problem with GRUB (and many other boot loaders as well) is that is does not fit into the MBR for booting Legacy/CSM systems. If the hard disk is MSDOS partitioned, it simply uses the space between the MBR and the 1st partition for a stage of the boot loader. (Usually 1MiB minus 512 Bytes of disk space) No problem here as long as no other stuff is using the "free" space between MBR and 1st partition as well.

The problem with GPT is that the partition table does not fit into the MBR. (The MBR holds both, primary partition table and boot code.) So it simply uses the "free" space between MBR and the 1st partition for its partition table.

Now try to use GPT on a non-UEFI systems which boots from MBR. Upps!

How to solve this issue: GRUB needs a different place on the hard disk. Therefore you can create a little extra "biosboot" partition, and tell GRUB during installation to place its extra boot code there.

On (U)EFI systems GRUB is not installing itself on the hard disk in any fixed sectors. Instead it will be installed as regular CentOS package, and will result in extra files in /boot/efi, i.e. the EFI System Partition (ESP). So there is no boot code of GRUB in the MBR, no boot code of GRUB in the "free" space of the hard disk, and no boot code of GRUB in a "biosboot" partition.

In that case I don't understand the error message.

If you have boot the rescue mode in (U)EFI, this error message does not seem to make sense. It seems that it does not detect that your computer is running in (U)EFI mode!?

I'm looking for a hex editor I can read the 1st sector with, but its definitely not 0s.

Which is totally fine. On GPT systems you have a "Protective MBR" partition in the MBR as well. Why? If there are only 0s in the MBR, an old application (unaware of GPT) could think that there is no partition on the hard disk and therefore plenty of free space. It could add an own partition. To pre vent this from happening GPT setups a MBR partition table as well, usually with a single partition spanning the whole disk.

[jddancks]

Well, I gave up and re-installed CentOS, and made sure that CentOS used the manually created EFI partition for Windows. Thats the way to do it. Thanks Owl.

[desertcat]

Well, I gave up and re-installed CentOS, and made sure that CentOS used the manually created EFI partition for Windows. Thats the way to do it. Thanks Owl.

OK If this is a "Trashcan Monster", can you lay your hands on another drive and stick it into the "Trashcan Monster"?? If so try this: Install CentOS 7 on the first drive, and set it up in legacy mode. This will create /boot/grub2/grub.cfg (ie Non-UEFI). Make sure it can boot in CentOS and all is well with the world.

Once you are sure CentOS is working remove the drive and stick in the second drive and install Windows (If this is a Transhcan Monster it can probably only run Windows 7 or below, it might not be able to handle Windows 10). Boot it and make sure that Windows comes up. Shutdown Windows and disconnect. Reinstall Disk #1 with Centos on it and boot from it so that Grub2 is the predominate bootloader. Shutdown . Hookup the Windows Drives so both drives are now live. Go into BIOS and under Boot Order make sure that the CentOS drive is the first drive to load. Bring up CentOS. Go over to /etc/grub.d and run 30_os-prober, it should now go out and find the other drive, and add it to the grub2 menu. The next time you boot the machine you should see the Windows boot option in the menu. You want to run Windows hit windows and up it should come.

One utility that will make your life that much easier is something called grub customizer It is easy to install run yum install grub-customizer.x86_64.

Here is another thing that might make your life easier as well:

https://dareneiri.github.io/Configuring ... -CentOS-7/

It will tell you how to "Configuring Grub2 on CentOS 7 to Duel Boot with Windows 7" and "This post assumes that Windows was installed first, and then CentOS was installed second."

Alternately maybe you need to think outside the box: IF after your best efforts you still can not get it to dual boot consider installing something like VMware Player and create a Virtual Machine of Windows whatever. Me? I HATE Windows and would NEVER install it on my Workstation, that said my SISTER Loves Windows 7 and some people I know have Windows 10. I thus run both as Virtual Machines . The nice thing about a Virtual Machine is that you can run both CentOS 7 *and* Windows concurrently and you don't need to choose one or the other to boot into: Boot into CentOS 7 and if you need to run Windows just simply fire up the Virtual Machine -- Problem Solved.

Hope this gives you some ideas.