Can GRUB2 work on a UEFI system without a small FAT partition at the beginning of the drive? Can the /boot/efi directory be on an EXT4 partition (such as root), or is there a compatibility problem with EXT4? If so, is there a good article someone can link to here, explaining GRUB2’s limitations?
When I checked in fdisk or gdisk, it listed my EXT4 partitions as: “Microsoft basic”. Is that standard behavior after a UEFI OpenSuse install? I changed the mislabeled partition types in GPT fdisk to 8300, and crossed my fingers that it wouldn’t wipe out the entire partition. I first tested it on root which is a partition I don’t care about losing, and it worked fine. Then I did it on home, and crossed fingers on both hands, and had no problem. GPT fdisk gives you a scary warning when you select “w”, after changing the partition type.
On Mon 27 Jan 2014 12:06:01 AM CST, pirithous wrote:
I have 2 questions:
Can GRUB2 work on a UEFI system without a small FAT partition at the
beginning of the drive? Can the /boot/efi directory be on an EXT4
partition (such as root), or is there a compatibility problem with EXT4?
If so, is there a good article someone can link to here, explaining
GRUB2’s limitations?
Hi
The ESP must be formatted FAT, FAT 16 for booting with a Windows OS
AFAIK (and which I always do), FAT 32 for linux and set to type
ef00 to be recognized. It needs to be on it’s own separate partition.
–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE 13.1 (Bottle) (x86_64) GNOME 3.10.2 Kernel 3.11.6-4-desktop
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
It needs to be FAT – either FAT16 or FAT32 will do. This is a requirement of the UEFI specification. The BIOS needs to be able to access the EFI partition, and that’s what is used as “/boot/efi”.
When you partition during install, “parted” is used for the partitioning.
My understanding, which might be wrong, is that until recently there was no official ID for ext4 partitions. And so “parted” does not know how to flag it as “ext4”, while the newer “gdisk” does. Presumably this will be corrected in future versions of “parted”, though it might require Yast installer changes, too.
In any case, my “ext4” partitions show a type code of “8300” in “gdisk”, probably because I partitioned with “gdisk” before installing. In any case, linux still works if the partition is wrongly identified.
Okay, here’s the “parted” output for “/dev/sdb”:
Number Start End Size File system Name Flags
1 1049kB 525MB 524MB fat16 EFI System boot
2 525MB 1050MB 524MB ext2 Linux filesystem
3 1050MB 119GB 118GB Linux LVM lvm
4 119GB 141GB 21.5GB ext4 Linux filesystem
5 141GB 151GB 10.7GB Linux swap
6 151GB 162GB 10.7GB Linux filesystem
So I guess “parted” is fine with the linux types, but maybe Yast has not caught up. Or maybe “parted” is getting that information from the actual file system, rather than from the partition type ID.
Windows 8 came with the ESP formatted to FAT 32. I allowed the EFI partition on my second disk to be formatted by opensuse install, and it used FAT 16. As far as I know, either FAT 16 or FAT 32 is allowed by the UEFI specifications, and perhaps even FAT12 is permitted.
On 2014-01-27 02:56, nrickert wrote:
> My understanding, which might be wrong, is that until recently there was
> no official ID for ext4 partitions. And so “parted” does not know how
> to flag it as “ext4”, while the newer “gdisk” does. Presumably this
> will be corrected in future versions of “parted”, though it might
> require Yast installer changes, too.
Another guess: this will only happen for GPT partitions, not MBR partitions.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
Further to this thread, to give a simple example of actual use, here is the /etc/fstab from my Ultrabook which has Windows8 and openSUSE in a dual boot:
where you can see there is a vfat mounted as /boot/efi
and here is the output of gdisk which is consistent with the above:
toshiba:/home/oldcpu # gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.7
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 500118192 sectors, 238.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): A9B29122-31C4-11E2-AF00-E8E0B773C368
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 500118158
Partitions will be aligned on 2048-sector boundaries
Total free space is 2669 sectors (1.3 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 923647 450.0 MiB 2700 Basic data partition
2 923648 1456127 260.0 MiB EF00 Basic data partition
3 1456128 1718271 128.0 MiB 0C01 Basic data partition
4 1718272 134838271 63.5 GiB 0700 Basic data partition
5 134838272 147945471 6.2 GiB 8200
6 468746240 487534591 9.0 GiB 2700 Basic data partition
7 487534592 500117503 6.0 GiB 8400 Basic data partition
8 147945472 200374271 25.0 GiB 0700
9 200374272 468746239 128.0 GiB 0700
where one can see that partition #2 , which is EF00, is my EFI partition. The partitions with nothing in the ‘Name’ column (5, 8, and 9) are the openSUSE partitions (swap, root and home). Then there is the EFI (already noted) and the remainder are associated with Windows8 and Toshiba putting in a recovery partition.