----- Original Message -----
| On Fri, Aug 19, 2016 at 4:59 PM, James A. Peltier <jpeltier@xxxxxx> wrote:
| >
| >
| > ----- Original Message -----
| > | On Thu, Aug 18, 2016 at 11:57 AM, James A. Peltier <jpeltier@xxxxxx>
| > | wrote:
| > | > Hi All,
| > | >
| > | > I have a Dell R710 that has 6x1TB in a RAID-5 configuration.
| > |
| > |
| > | This is hardware RAID 5? Because it's pretty screwy how this ends up
| > | working when using software RAID and might take additional
| > | troubleshooting.
| >
| > Yes, it's a Dell R710XD
| >
| > | > When installing CentOS 7 using the full disk capacity and booting in
| > | > UEFI
| > | > mode the machine dumps me into a GRUB rescue mode prompt.
| > | > error: disk `,gpt2' not found
| > | > Entering rescue mode...
| > | > grub rescue>
| > |
| > |
| > | This is confusing to me because there should be no such thing as grub
| > | rescue on UEFI. On BIOS systems, there is boot.img (formerly stage 1)
| > | and core.img in the MBR gap or on BIOS Boot if GPT disk (formerly
| > | stage 1.5 and stage 2). The core.img is where grub rescue comes from
| > | when it can't find grub modules, in particular normal.mod.
| > |
| > | But on UEFI, core.img, normal.mod, and a pile of other modules are all
| > | baked into the grubx64.efi file founds on the EFI system partition.
| > |
| > | I suspect two things that can cause normal.mod to not be found:
| > | a. The system is not in fact booting in UEFI mode and there's been
| > | some mistake in the installation of grub.
| > | b. The system is in UEFI mode, but either the installer, or
| > | post-install, grub2-install was run which obliterates the grub2-efi
| > | package installed grubx64.efi, i.e. it's not really proper to run
| > | grub2-install on UEFI systems.
| >
| > I suspect this is the case. when attempting to run grub-install the system
| > claims that the grub2-efi-modules packages aren't installed, so this may
| > be an installer bug.
|
| What is attempting to run grub-install? Or even grub2-install? If the
| installer is doing this, it's an installer bug. If the user is doing
| it, it's user error.
|
| Also, you will need to check the NVRAM for stale values because
| grub2-install also populates NVRAM with what will become the wrong
| entry. You'll need to use 'efibootmgr -v' to get a listing to find the
| bogus entry, which will be pointing to a path that includes
| grubx64.efi, note the boot number and then do 'efibootmgr -b <bootnum>
| -B' Where bootnum is the four digit value for the bogus entry.
|
| What should happen if there are no valid entries is shim.efi will work
| with fallback.efi to create a proper NVRAM entry. The proper entry can
| be found with the earlier grep efibootmgr command, and you can just
| use that, while adding an additional \ for each \, so that it's \\.
| NVRAM should point to shim.efi and it's shim.efi that loads the
| prebaked grubx64.efi.
When running grub2-install from within recovery mode I can assure you it is not a user error because simply installing the grub2-efi-modules package allows for grub2-install to work. We will try the efibootmgr -v out too.
--
James A. Peltier
IT Services - Research Computing Group
Simon Fraser University - Burnaby Campus
Phone : 604-365-6432
Fax : 778-782-3045
E-Mail : jpeltier@xxxxxx
Website : http://www.sfu.ca/itservices
Twitter : @sfu_rcg
Powering Engagement Through Technology
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
