GPT UEFI Partitioning Query

[FastTurtle]

I'm attempting to use an EFI-stub kernel on a GPT (gparted) partitioned/formated disk yet Grub 2 does not see the /boot partition (linux-ext2). In fact grub2 gave me an error about not finding a partition to install on so I'm not sure what in heck went wrong - had left 3M of space free before the /boot partition for Grub2 to install it's files in.

What I'm thinking was the problem was that the /boot was labeled as Linux (8300) instead of the needed ef00 for an ESP so any information would be appreciated.

Another thing is that I'm seeing lots of efi_stub kernels that use one of the efi packages such as refind in place of grub. Links appreciated on how to configure such to show now only various gentoo but a Win7-64 kernel (Yes! it's efi aware as you can install on a Mac).

[khayyam]

What I'm thinking was the problem was that the /boot was labeled as Linux (8300) instead of the needed ef00 for an ESP so any information would be appreciated.

FastTurtle ... the efi executable needn't be on an ESP or partition marked as EF00, Apple for instance stores their EFI loader in /System/Library/CoreServices/ on the OS partition. The EFI specification uses {ESP}/efi/boot/boot{x64,ia32}.efi as the default but you can modify efivars to point to wherever the efi executable is located.

Code: Select all

# modprobe efivars
# efibootmgr -v
BootCurrent: 0000
Timeout: 5 seconds
BootOrder: 0000
Boot0000* rEFInd	HD(1,28,64000,a5d32078-64a7-4c13-a0f1-1286c2f6422b)File(\efi\refind\refind_ia32.efi)

This states the efi executable (here refind_ia32.efi) is located on HD(x) (the ESP ... EFI System Partition, EF00) with the path '\efi\refind\'.

This entry was created with the following:

Code: Select all

# efibootmgr --create --part 1 --label "rEFInd" --loader "\efi\refind\refind_ia32.efi"

You could do the same with your efi_stub, changing the path to '--loader', '--label' and '--part' (here '1' corresponds to the first partition, the ESP).

Another thing is that I'm seeing lots of efi_stub kernels that use one of the efi packages such as refind in place of grub. Links appreciated on how to configure such to show now only various gentoo but a Win7-64 kernel (Yes! it's efi aware as you can install on a Mac).

Using a bootmanager (like rEFInd) means that when updating a kernel no changes to efivars are required. rEFInd will search the hardisk looking for efi executables and offer them as boot options (so, in my case I simply add the new kernel to {ESP}/vmlinuz-{version}.efi and the next boot this is offered as the first available ... as it uses modification time to order them). rEFInd can also be supplied a 'refind_linux.conf' with boot parameters, (so no changes to the config file are needed) or configured to search/load/offer, kernels in a certain place (obviously having rEFInd autodetect and offer them is generally preferable to editing the config on the addition of new kernels). So, in short using a boot manager simplifies the whole process of updating, booting efi_stub/kernels, and selecting boot parameters. While you needn't use one,using a bootmanager is more flexable (also when not using a bootmanager you'd need to add boot parameters to the kernel itself in menuconfig, and there is no method of changing/modifying them at boot time).

I don't have windows installed but refind should detect it and offer it as a boot option.

For the sake of completeness here is my {ESP}/refind_linux.conf

Code: Select all

"Boot softlevel default"  "quiet ro nopat threadirqs video.use_native_backlight=1 rootfstype=ext4 luks enc_root=/dev/sda2 lvm root=/dev/mapper/vg-root swsusp resume=/dev/mapper/vg-swap"
"Boot softlevel online"   "quiet ro nopat threadirqs video.use_native_backlight=1 rootfstype=ext4 luks enc_root=/dev/sda2 lvm root=/dev/mapper/vg-root swsusp resume=/dev/mapper/vg-swap softlevel=online" 
"Boot softlevel single"   "quiet ro nopat threadirqs video.use_native_backlight=1 rootfstype=ext4 luks enc_root=/dev/sda2 lvm root=/dev/mapper/vg-root swsusp resume=/dev/mapper/vg-swap softlevel=single"

The first entry is the default (both for parameters passed to the kernel, and the runlevel passed to openrc via softlevel) if I need to change those I can do so when in refind by hitting F2.

best ... khay

[FastTurtle]

so refind is a replacement for lilo/grub (grub2 )

On the ESP partition, don't know if the MS boot loader needs it since I'm not using that option as yet (have to test with the CD as my flash drive installer doesn't have the needed efi kernel)

[DONAHUE]

so refind is a replacement for lilo/grub (grub2 )

not exacly; rEFInd is a boot manager which can be used to choose among several bootloaders. grub legacy and 2 combines manager and loader, lilo is just loader IIRC

[vaxbrat]

Grub2 wants an EF02 partition number. I think it only really needs 2mb as a bare minimum. Note that this is before /boot which you can keep as is. It ends up parking additional grub2 code in there which would be too big for the classic MBR boot code scheme. I run the following scheme on a MythTV box where I have the system root setup as a btrfs subvolume.

Code: Select all

tube ~ # gdisk /dev/sda
GPT fdisk (gdisk) version 0.8.10

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/sda: 500118192 sectors, 238.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): FD999B21-5639-44BD-BE36-AC0E264ACBFC
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 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048            8191   3.0 MiB     EF02  biosboot
   2            8192         1032191   500.0 MiB   8300  boot
   3         1032192       500118158   238.0 GiB   8300  root

[srs5694]

Grub2 wants an EF02 partition number.

This is true when booting in BIOS/CSM/legacy mode from a GPT disk; but in EFI/UEFI mode, this partition will be useless. FastTurtle implies that s/he is booting in EFI mode, but the error message from GRUB might indicate a BIOS-mode version of GRUB. (The exact error message would be useful in making this determination. General tip: Don't summarize error messages; quote them exactly.)

One other point: The type code EF02 is a gdisk convention that's not used by (most) other partitioning tools. GParted and parted, for instance, identify such partitions as having a "bios_grub flag" set. More generally, this partition is known as a BIOS Boot Partition. You can blame the use of 128-bit (16-byte) type codes in GPT for the multiple ways to identify partitions; these codes are awkward enough that partitioning programs try to "translate" them to something easier to type and remember.

I think it only really needs 2mb as a bare minimum.

The precise size required for the BIOS Boot Partition varies depending on your GRUB version and what features you're using. It can be as small as about 30KiB (I'm unsure of the precise lower limit). In most cases, 1MiB is big enough, and most automated tools create the partition at that size. I've seen claims from some people that 1MiB has been insufficient for them, and these people have gone as large as 2MiB. I have yet to see claims that it needs to be bigger than that, although I have seen posts from people who've created larger BIOS Boot Partitions. Doing so is a waste of disk space, but AFAIK does no other damage.

All of this is irrelevant, of course, if the computer is booting in EFI mode. In that case, a FAT EFI System Partition (ESP) must be present, and it must hold boot program(s) such as GRUB, rEFInd, the Windows boot loader, etc. Sometimes it's convenient or even necessary to put Linux kernels on the ESP; the details depend on your boot loader.

[khayyam]

[...] in EFI mode. In that case, a FAT EFI System Partition (ESP) must be present, and it must hold boot program(s) such as GRUB, rEFInd, the Windows boot loader, etc.

srs5694 ... hmmm, so I was wrong above? I ask because Apple's diskutils creates an ESP but the OS doesn't use it, the actual efi executable is stored on the OS partition. At least this was the case the last I looked, which admittedly is some many years ago.

best ... khay

[srs5694]

[...] in EFI mode. In that case, a FAT EFI System Partition (ESP) must be present, and it must hold boot program(s) such as GRUB, rEFInd, the Windows boot loader, etc.

srs5694 ... hmmm, so I was wrong above? I ask because Apple's diskutils creates an ESP but the OS doesn't use it, the actual efi executable is stored on the OS partition. At least this was the case the last I looked, which admittedly is some many years ago.

Yes and no. Apple, like Microsoft, often plays fast and loose with the rules. In the case of EFI, Apple deviates in significant ways on many levels, and one of these is on the role of the ESP and where boot loaders reside; EFI's ESP is normally empty, and its boot loader lives on the OS X root (/) partition. Apple can do this because they include an HFS+ driver in their EFI implementation. (This doesn't actually violate the EFI spec, but it is a non-standard extension, and so is something that programs and users should not assume is present.) Apple also modifies the boot process so that the usual EFI NVRAM boot manager isn't quite the same as it is on more normal implementations.

A standard EFI can only read FAT, so the primary boot program read by the EFI must reside on a FAT partition. Many ESPs don't actually pay attention to the type code, so you can sometimes play fast and loose with the ESP type code; but the boot loader really does need to reside on a FAT partition. Once the primary boot program is loaded, it can load an ancillary driver (like the ones included with rEFIt and rEFInd, or that are part of the new efifs project), which then broadens possibilities. To date, this capability is used mostly by rEFInd to run a Linux kernel with EFI stub loader from a non-ESP partition. In this scenario, though, both rEFInd and its filesystem driver(s) must reside on a FAT filesystem.

So there is considerable nuance here. In general, though, it's best to deal with the lowest-common-denominator case of an EFI that understands nothing but FAT. Apple's EFI is a special case, and one that deviates from the standard in other ways, too.

[ct85711]

I did manage to install windows 7 on UEFI; and one thing I will mention for windows wise is that it doe require a esp drive (the partition only needs to be on one of the drive, windows will accept having the ESP partition on a different drive than what windows is installed on. One issue I encountered when installing windows 7, is that by default (at least for me) it does not install in UEFI mode, I had to use a usb boot drive to boot the windows installer in UEFI. Also Windows 7 will also make a second partition, a Microsoft reserved (mine was 128MB), with the Microsoft basic data being the normal partition with the windows files and stuff. I am using grub2 by it's self as my bootmanager (also supports dual booting into windows) without refind used at all. Included below is my partition setup.

Code: Select all

/dev/sda
   1            2048          976895   476.0 MiB   EF00  ESI    (EFI drive, FAT32)
   2          976896         8790015   3.7 GiB     8200  primary (linux swap)
   3         8790016       156301311   70.3 GiB    0700  primary  (linux system)
/dev/sdb
   1            2048          264191   128.0 MiB   0C01  Microsoft reserved  (?, automaticaly created by windows installer)
   2          264192       409602047   195.2 GiB   0700  Basic data partition  (windows files)
   3       409602048      1953525134   736.2 GiB   8300  Linux filesystem  (/home partition)

[FastTurtle]

Donahue:

My system is a full UEFI boot with Win7 as primary, Gentoo is secondary.
Reading the refind install docs, it appears I'll have to use the manual method but forgo doing it from windows other then extracting and removing things not needed such as the ia32.efi.

Question in regards to kernel naming/config:

is it mandantory to include the efi-stub feature in the kernel to boot on an efi system?

Khayyam:

for a straight boot of an efi-stub kernel (supposedly supported by the standard), I can use foo_x64.efi for the efivars/efibootmgr to set things correctly?

Hadn't thought about the diff between a loader and manager but can see it now that it's pointed out. On refind, all I'd need to do is copy the /refind directory to the ESP? The manual install doc isn't very clear on this point and would I use the efibootmgr to establish refind as the main boot system? as it looks as though the manual states using bcdedit (windows tool) to change things but of course MS has to protect the user from themself even if they can mount the volume. <rant> if I didn't need windows (onenote mainly) I'd simply blow it off the system and use Gentoo.</rant> Nice thing about full system backups, it's possible to do that and say to hades with ye!

[ct85711]

I can't really say if the efi stub is required in the kernel to boot an efi system, I myself, have it enabled even though I don't use the efi stub to boot my system. I still go through grub2 to boot my efi system perfectly fine. I would mention, you may want to check in your bios; as some bios has an option built in to switch to the default boot system. My MB/bios has that option; so after I installed windows (of course windows has to set it's self as default); I just used my bios to change it back and it worked perfectly fine.

From my understanding (and partly of when I tested it out), when you install refind, it'll automaticaly set it's self up as the main boot system, assuming you use the install script. Otherwise if you do the manualy installation you will have to use efibootmgr to set it up (along with coping refind to the esp). (Again, assuming you are using an ESP partition; which windows requires in addition to the extra partion it requires, not counting the normal data partition. So in short Windows in efi mode, needs 3 partitions total.)

[DONAHUE]

efi-stub is a bootloader, if you use another bootloader you don't need it
the worst case uefi board I worked on refused to honor efibootmgr (would only allow one uefi partition, to boot windows that had to be windows, the windows ESP would only honor bcdedit) thus the wiki was written to use bcdedit to implement refind. The file copying and editing of placing rEFInd on the ESP can be done in linux.
The rEFInd with efistub combination is my preference as there is no extra maintenance when a new kernel is compiled.

[FastTurtle]

ct85711: the ESP partition is actually defined in the UEFI Specs and MS got their way by requiring it to use fat as the format.

Well I've decided to nuke windows from orbit - Hell I'm gonna Death Star it - and do a clean Gentoo install. It'll be the only thing on the system.

[FastTurtle]

Got it working but still not fully stable.

On the refind script, if you're trying to use it from a SysRescue cd, the efibootmgr stage fails for some reason. If you use the sysresc cd to boot the kernel, efibootmgr and such all work properly - still haven't figured that out. Have finished restoring Win7 and all the blasted updates with everything but it's drive disconnected. When the others were connected the first thing windows wanted to do was format them while having no working USB (xhci/usb3 w/o driver installed). Murphy has really worked overtime the last few days but I've managed to keep him at bay (knock on wood) and should be able to get refind installed as the boot loader this weekend. Have to finish restoring files from backup so I'm at least operational.

[FastTurtle]

It Lives - Somewhat. Gentoo now boots and is partly usable. Had to edit the refind_linux.conf entries that used the UUID for rootfs instead of the PARTUUID. Note that I'm using the kernel command line to boot and will be testing the refind_.conf to ensure it's now working.

A problem I suspect is related is that Windows wont boot using refind - suspect it's the UUID being used instead of the PARTUUID - could be wrong.

I'm using the refind-bin-0.8.3 file and installed using the install.sh script. Worked like a charm once I though to boot the Gentoo system using the System Rescue disk so I'm in full UEFI mode for both Windows and Gentoo.

Minor issues to address is the clock skew being detected - will add an ntp-client to fix that problem.