How to check if I'm using GRUB-EFI or GRUB-PC?

Question

I'm running Ubuntu 14.04 in a chroot on ChromeOS, which uses a UEFI system. In order to install WinUSB to create recovery media for Windows, I had to change grub-efi-amd64 to grub-pc. WinUSB performed this process for me. To my knowledge this would render my device unable to boot.

In an attempt to correct this, I ran sudo apt-get install grub-efi which may have fixed the issue, but I don't want to reboot to find out in case I'm wrong.

How would I go about checking if the problem is fixed?

I've been told that I could run sudo grub to enter the grub shell and then echo $grub_install to tell me if I'm using grub-pc or grub-efi-amd64. However, I'm using GRUB 2.02 and sudo grub appears to be deprecated.

As I'm on a Chromebook, which always boots into ChromeOS, I have no way of accessing a GRUB shell at boot.

Can anyone help me?

Solution

See this question to determine how your computer was booted:

How can I tell if my system was booted as EFI/UEFI or BIOS?

This isn't quite the same as the question you asked, which is why I'm not marking your question as a duplicate. Ordinarily, the boot method (BIOS vs. EFI) determines which version of GRUB was the last one to boot the computer. (If you have other boot loaders installed, of course, you could have booted through one of them; this approach won't distinguish between, say, EFI-mode GRUB and EFI-mode ELILO.)

You can check to see which version of the GRUB package is installed by using your package manager, as in:

dpkg -l | grep grub | grep ii

Boot loaders like GRUB are unusual, though, in that installing the package is distinct from inserting the boot loader into the boot process. Normally, you install the Debian package and then use its files to insert the boot loader into the boot process; but the latter can be done without a package, and a package can be installed without the boot process being altered. In fact, in your case you might have both the BIOS and EFI versions of GRUB available as boot options.

The simplest way to check to see what's accessible as boot options is to use the Boot Info Script. This script will produce a file called RESULTS.txt that will report what boot loaders are available; however, it requires some knowledge to interpret the output. BIOS-mode boot loaders show up something like this, near the top of the output:

============================= Boot Info Summary: ===============================

 => Grub2 (v1.99) is installed in the MBR of /dev/sda and looks at sector 40 
    of the same hard drive for core.img, but core.img can not be found at this 
    location.

EFI-mode boot loaders are stored as files on the EFI System Partition (ESP). These files will show up in the output something like this:

sda1:     __________________________________________________________________________

    File system:       vfat
    Boot sector type:  FAT32
    Boot sector info:  No errors found in the Boot Parameter Block.
    Operating System:  
    Boot files:        /EFI/Boot/bootx64.efi /EFI/ubuntu/MokManager.efi 
                       /EFI/ubuntu/fwupx64.efi /EFI/ubuntu/grubx64.efi 
                       /EFI/ubuntu/shimx64.efi 
                       /EFI/Microsoft/Boot/bootmgfw.efi 
                       /EFI/Microsoft/Boot/bootx64.efi

Note in particular the /EFI/ubuntu/grubx64.efi file, which is GRUB. (/EFI/ubuntu/shimx64.efi handles Secure Boot, and other files, especially in /EFI/ubuntu, can be relevant, too.) If you're using an EFI boot loader other than GRUB, it may show up somewhere, too.

In addition, EFI-mode boot loaders are normally referenced by entries stored in NVRAM, which the Boot Info Script will identify via runs of efibootmgr:

=================== efibootmgr -v
BootCurrent: 0004
Timeout: 0 seconds
BootOrder: 0000,0002,2001,2003,2002
Boot0000* ubuntu    HD(1,GPT,249432ce-52fe-4533-b029-ba6c1a901382,0x800,0x100000)/File(EFIubuntushimx64.efi)
Boot0001* EFI Network 0 for IPv4 (68-F7-28-DA-88-B8)    PciRoot(0x0)/Pci(0x2,0x4)/Pci(0x0,0x0)/MAC(68f728da88b8,0)/IPv4(0.0.0.0:0<->0.0.0.0:0,0,0)RC
Boot0002* Windows Boot Manager  HD(1,GPT,249432ce-52fe-4533-b029-ba6c1a901382,0x800,0x100000)/File(EFIMicrosoftBootbootmgfw.efi)RC
Boot0003* EFI Network 0 for IPv6 (68-F7-28-DA-88-B8)    PciRoot(0x0)/Pci(0x2,0x4)/Pci(0x0,0x0)/MAC(68f728da88b8,0)/IPv6([::]:<->[::]:,0,0)RC
Boot0004* EFI USB Device (Generic Flash Disk)   PciRoot(0x0)/Pci(0x12,0x0)/USB(0,0)/USB(0,0)/HD(1,MBR,0x4294967218,0x800,0x1f6a800)RC
Boot2001* EFI USB Device    RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network   RC

Note that efibootmgr is usable only from an EFI-mode boot, so if you booted in BIOS mode, you won't see this output, even if an EFI boot loader is available. Also, some EFIs are buggy and forget or ignore EFI boot entries, but they can usually still be booted in EFI mode by using various ugly workarounds.

Anyhow, the efibootmgr output looks scary and complex, but the key points are:

• If GRUB is properly configured, a Boot#### entry should point to it. In the case of Ubuntu, it should be called ubuntu, so look for an ubuntu entry -- Boot0000 in this case. (The number could be any hexadecimal value.)
• BootOrder shows the order in which boot entries are tried. In this case, 0000 is first, which means that the Boot0000 entry (ubuntu) will be tried first.

The point of all this is that you might have both BIOS-mode and EFI-mode versions of GRUB available for use by the firmware. If so, both will show up in the Boot Info Script output, and it will be hard to tell which one will actually be used. For that, checking your current boot mode is the best approach. Occasionally, confusion can occur, or you might switch from one boot mode to another. Removing redundant boot loaders can help avoid confusion, but this can be risky -- particularly removing a BIOS-mode boot loader from an MBR, since this requires use of dd, which can easily trash your disk if you make a mistake. It's generally best to leave unused boot loaders accessible to the firmware rather than risk such disasters.

Comments

[WinEunuuchs2Unix]

run the command ls /boot/grub and report the results please.

[snazzybouche]

fonts grub.cfg grubenv i386-pc locale unicode.pf2 Of those, 1st 4th and 5th are coloured blue, rest white.

[WinEunuuchs2Unix]

I believe i386-pc(blue indicates sub-directory) indicates you are running grub-pc version (in your terminology).

[snazzybouche]

Apologies, wasn't aware that "grub-pc" was incorrect. Would this indicate that I'm currently unable to boot? If so, could you recommend a step to resolve this? Thanks for your answer.

[WinEunuuchs2Unix]

Unfortunately I avoid UEFI like the plague so cannot give advice. I did the second best thing which is to upvote your question to help bring more attention to it.