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 msftdataThe 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 dataI 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.
5 Answers
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/sda2FWIW, 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 /bootIf 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/efiAlthough 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.
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.
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 /bootIf you are installing this on virtual-box make sure you have the enabled the option of EFI under the category of Setting/System
1The 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.
