9

I need a Gentoo 13 machine to test some software on the platform. I'm not a Gentoo regular, so I'm suffering their install procedures. I'm at Configuring the bootloader | Installing GRUB2, and it failed with:

# grub2-install --target=x86_64-efi --efi-directory=/boot
Installing for x86_64-efi platform.
grub2-install: error: /boot doesn't look like an EFI partition.

I backtracked to Preparing the disks | Default: Using parted to partition the disk, and it appears I have things setup as instructed:

(chroot) Gentoo-2012 / # parted
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit mb                                                          
(parted) print                                                            
Model: ATA VMware Virtual I (scsi)
Disk /dev/sda: 21475MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End      Size     File system     Name    Flags
 1      1.05MB  3.15MB   2.10MB                   grub    bios_grub
 2      3.15MB  131MB    128MB    ext2            boot    boot, esp
 3      131MB   2572MB   2441MB   linux-swap(v1)  swap    msftdata
 4      2572MB  21474MB  18902MB  ext4            rootfs  msftdata

The results above are from the same chapter of the manual, sections Applying a filesystem to a partition and Activating the swap partition.

I also followed the comment EFI directory should not be /boot but /boot/efi from Bootloader problems and questions on the Gentoo forums, but it resulted in the same error:

(chroot) Gentoo-2012 / # mkdir /boot/efi
(chroot) Gentoo-2012 / # grub2-install --target=x86_64-efi --boot-directory=/boot --efi-directory=/boot/efi
Installing for x86_64-efi platform.
grub2-install: error: /boot/efi doesn't look like an EFI partition.

What's the problem and how do I fix it?

Here's the corresponding fdisk view of the information presented by gparted above.

(chroot) Gentoo-2012 / # fdisk -l
Disk /dev/loop0: 3.3 GiB, 3567640576 bytes, 6968048 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes    

Disk /dev/sda: 20 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 52F5571A-808B-XXXX-XXXX-XXXXXXXX

Device       Start      End  Sectors  Size Type
/dev/sda1     2048     6143     4096    2M BIOS boot
/dev/sda2     6144   255999   249856  122M EFI System
/dev/sda3   256000  5023743  4767744  2.3G Microsoft basic data
/dev/sda4  5023744 41940991 36917248 17.6G Microsoft basic data

I also verified the package sys-boot/grub supports EFI:

(chroot) Gentoo-2012 / # cat /etc/portage/make.conf | grep GRUB
GRUB_PLATFORMS="emu efi-32 efi-64 pc"

I then performed an emerge --ask --newuse sys-boot/grub, emerge -pv sys-boot/grub, and then rebuilt grub.

Improve this question
5
  • Try mkdir, then rebooting, and executing grub2-install --target=x86_64-efi --boot-directory=/boot --efi-directory=/boot/efi
    – Joseph
    Commented Mar 15, 2016 at 23:46
  • @bytec0de - Thanks. If I reboot, then the machine won't boot because it won't have a boot loader. I'd feel much better about the current OS in a state it can proceed. How do I force a re-read of the disk partitions (is that what needs to be done)?
    – jww
    Commented Mar 16, 2016 at 0:02
  • @bytec0de - I tried the reboot, but it won't reboot. The error message is "operating system not found". Can I ask you... did you know what the problem was, or were you guessing? The best I can tell, two days worth of work is now gone...
    – jww
    Commented Mar 16, 2016 at 1:37
  • It was an educated guess @jww, which is why I commented.
    – Joseph
    Commented Mar 16, 2016 at 13:23
  • If you're here and you used fdisk to prepare your partitions on the disk, then it says right in the manual: "grub is going to give you some serious problems if you use fdisk, and you're on your own". Their solution is to follow the manual's advice and prepare your disks using the parted tool, and using that to label your disks using the GPT flags. Then the grub-install won't complain about: "What the partition looks like".
    – Eric Leschinski
    Commented Sep 25, 2020 at 14:02

5 Answers 5

Reset to default
18

The answer is simple. EFI System Partition (ESP) should be FAT32 (FAT16 or even FAT12 will also do for most proper UEFI; they are mostly shown as vfat in Linux) instead of ext2:

mkfs.fat -F32 /dev/sda2

FWIW, if you are not going to install grub i386-pc (for BIOS/CSM boot), you don't need the "BIOS boot" partition. It is only required by grub i386-pc (but not grub x86_64-efi or i386-efi) on GPT.

It doesn't really matter whether you use the ESP for /boot. If you do, you should run:

grub2-install --efi-directory /boot

If you mount it on /boot/efi instead, then you should run:

grub2-install --efi-directory /boot/efi

--boot-directory /boot is implied (i.e. default); It doesn't matter whether /boot is the ESP, another separate partition, or a directory on the / filesystem.

You may not even need to chroot again to perform grub2-install; For example, you mounted sda4, your partition for /, on /mnt; AND THEN, mounted sda2, your ESP, on /mnt/boot/efi, then you can simply run:

grub2-install --boot-directory /mnt/boot --efi-directory /mnt/boot/efi

Although grub2-mkconfig needs to be run in chroot AFAIK. But if you plan on writing a simple and clean grub.cfg yourself instead (which is the only graceful way to use grub2), then this will be out of your concern.

Improve this answer
8
  • Thanks Tom. It looks like their manual is pretty much broken in this area. Let me try some of these things and get back to you.
    – jww
    Commented Mar 16, 2016 at 3:18
  • 1
    Thanks again Tom. I performed the mkfs.fat -F32 /dev/sda2. I mounted things again as per the manual, and I was able to run grub2-install --target=x86_64-efi --boot-directory=/boot --efi-directory=/boot/efi/ with some warnings. grub2-install completed with "Installation finished. No error reported." However, it does not boot, and produces an error "operating system not found". No wonder these guys don't produce a LiveCD that performs an installation. Based on their instructions, it can't be done.
    – jww
    Commented Mar 16, 2016 at 3:58
  • As per the manual? What does that mean? Tell the mount commands you ran IN ORDER. Also considering the params you used, have you chrooted? Usually you can't really ignore "warnings" from grub2-install, so please show what exactly they are.
    – Tom Yan
    Commented Mar 16, 2016 at 4:00
  • Thanks again Tom. Sorry about that; I thought you were familiar with the procedures. The disks were mounted according to Preparing the disks | Mounting. Chroot was entered according to Installing the Gentoo base system | Mounting the necessary filesystems. I had to Chroot because I got an error without it. The error was "grub2-install: error: /usr/lib/grub/x86_64-efi/modinfo.sh doesn't exist."
    – jww
    Commented Mar 16, 2016 at 4:15
  • It's not about the "procedures" or whether I am familiar with them. It's HOW YOU mounted YOUR devices. So did you mount /dev/sda4 /mnt/gentoo; mount /dev/sda2 /mnt/gentoo/boot/efi in this ORDER and chroot to /mnt/gentoo? Again, what were the warnings you mentioned?
    – Tom Yan
    Commented Mar 16, 2016 at 4:20
3

The problem seemed to be mixing and matching BIOS, EFI, MBR, and GPT. I tried to follow the guides and use the GPT, but there were some dependencies that I could not resolve because I am too inexperienced. Its not even clear to me the kernel was built with GPT support (via config option CONFIG_EFI_PARTITION).

When I dropped GPT and EFI and switched to purely BIOS and MBR, I was able to boot the resulting machine. BIOS and GPT are supposed to be a valid combination, but I'm wondering if it works in practice (see, for example, Bootloader Options).

Here's the configuration I was able to run the machine with:

$ parted
GNU Parted 3.2
Using /dev/sda
(parted) print                                                            
Model: ATA VMware Virtual I (scsi)
Disk /dev/sda: 21.5GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system     Flags
 1      1049kB  135MB   134MB   primary  ext2            boot
 2      135MB   19.5GB  19.3GB  primary  ext4
 3      19.5GB  21.5GB  2012MB  primary  linux-swap(v1)

Partition 1 is /boot, Partition 2 is /, and Partition 3 is swap.

Improve this answer
5
  • You don't even necessarily need GPT for a standard-conforming UEFI, and you were able to mount partitions on a GPT disk. You just didn't have grub's EFI binary successfully registered in your UEFI's NVRAM, as the warnings of grub2-install clearly told you. And no matter what the reason is, --removable should be able to help you out (unless its sharing a Windows's ESP).
    – Tom Yan
    Commented Mar 18, 2016 at 7:07
  • @TomYan Are you saying that 'error: /boot doesn't look like an EFI partition.' is clearly telling him that he's missing something in NVRAM? Because I'm having this problem right now on arch linux, and I feel it MIGHT be due to a standard WIn 7 (64-bit) boot partion being NTFS instead of FAT32, but that doesn't really seem possible as I thought it HAD to be FAT of some sort (even though parted seems to say NTFS)
    – ebyrob
    Commented Sep 18, 2019 at 16:54
  • @ebyrob the error pretty much means you are passing --efi-directory /boot while whatever mounted on /boot is not a FAT(32) filesystem. If you have an existing Win7 installation, which is most likely not UEFI-bootable, you can either install grub for legacy/BIOS/MBR booting (--target i386-pc), or, create a FAT(32) formatted partition yourself as the EFI system partition and install grub for UEFI booting. The caveat of the latter approach is that you can only switch between Windows and Arch with the UEFI boot menu but not grub's. Anyway, you should NOT mount any existing Windows partition.
    – Tom Yan
    Commented Sep 21, 2019 at 2:07
  • @TomYan Win7 x64 boots from an NTFS partition. Probably hence the confusion on my part. Installing Ubuntu worked fine (And Debian has worked in the past). I'm not quite sure how Arch Linux should multi boot with win7... I know Ubuntu uses UEFI booting, I thought Ubuntu uses GRUB, but perhaps it doesn't.
    – ebyrob
    Commented Sep 22, 2019 at 14:58
  • @ebyrob It doesn't really have anything to do with distro. You can install different variant (a.k.a. target) of grub for different mode of booting on most UEFI ("native" or legacy). The variant you install determines how you multi-boot (i.e. where/when you select the OS to boot), as you can't change the boot mode once grub is loaded. That's why if you installs UEFI grub, you can only choose to boot your Win7 (which can only be legacy boot) with your UEFI boot menu.
    – Tom Yan
    Commented Sep 22, 2019 at 15:14
3

I just had this issue and found that /boot existed but didn't have my boot partition mounted to it. Just had to mount the boot partition to fix this

mnt /dev/sda1 /boot
Improve this answer
1
  • Thanks, I almost deleted my /boot part for no reason!
    – trinaldi
    Commented Jul 17, 2023 at 21:12
2

If you are installing this on virtual-box make sure you have the enabled the option of EFI under the category of Setting/System

Improve this answer
0
0

The Error:

$> grub2-install --target=x86_64-efi --efi-directory=/boot

Installing for x86_64-efi platform.
grub2-install: error: /boot doesn't look like an EFI partition.

Inspecting the source for grub2, it seems to demand that /boot be its own file allocation table (FAT) compliant separate partition, maybe for security reasons, It wasn't this way before. grub2 has caved to security conditions inflicted by the motherboard.

I'm doing this on a 2020 x86_64 PC desktop and I chose not to create a separate /dev/sda1 boot partition, on /dev/sda, (marked as bootable during the fdisk /dev/sda step).

Solution1:

Disable any Bios Secure Boot settings in the motherboard's boot startup BIOS/EFI/UEFI utility, and look for any Boot level security settings to disable. Assuming you don't like security. It may be a setting under F7 -> boot -> secure boot.

Solution2:

Cave to grub's new security demands, and follow the manual for creating your own separate partition for /boot and grub config steps.

The EFI System Partition (ESP) must be a FAT filing system variant (sometimes shown as vfat on Linux systems). The official UEFI specification denotes FAT12, 16, or 32 filesystems will be recognized by the UEFI firmware, although FAT32 is recommended for the ESP. Angry noises that optional steps from many moons ago are now required steps.

Solution 3:

The fdisk tool appears to be depreciated and marked for removal. The manual says: "You're going to have problems if you use fdisk, and you're on your own." Their solution is to scroll up on the manual and follow the directions on using parted to create your partitions, and mark the boot partition with their suggested bios_grub flag. Then tada, automatically grub knows where to look and what to do.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .