Project

General

Profile

Bug #14414

Avatar?id=14398&size=22x22

Add UEFI Boot Support

Added by Michael Dexter over 4 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
Important
Assignee:
Kris Moore
Category:
OS
Target version:
Seen in:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

Annie is fielding requests for UEFI support in FreeNAS, as is Dexter.
Requested by: Public, Dexter
Discussed with: kmoore who has implementation details and code


Subtasks

Bug #15778: UEFI support for upgradesResolvedSean Fagan
Bug #15779: UEFI support for replacing disk in boot poolResolvedWilliam Grzybowski

Associated revisions

Revision 18d00df2 (diff)
Added by Kris Moore over 4 years ago

Add initial support for UEFI installs to FreeNAS This updates grub2-pcbsd with some needed kernel settings (Vt) and updates the sysutils/grub2-efi with a later version. Lastly it updates the installer to determine if we are UEFI booted or not, and DTRT if so. Ticket: #14414

Revision a1c1ba40 (diff)
Added by Kris Moore over 4 years ago

Enable building ISO's with UEFI boot support Ticket: #14414

Revision 5da108e1 (diff)
Added by Kris Moore over 4 years ago

Add initial support for UEFI installs to FreeNAS This updates grub2-pcbsd with some needed kernel settings (Vt) and updates the sysutils/grub2-efi with a later version. Lastly it updates the installer to determine if we are UEFI booted or not, and DTRT if so. Ticket: #14414 (cherry picked from commit 18d00df28ba13aec779945b2ecbbc85f15df49ad)

Revision aae2ade5 (diff)
Added by Kris Moore over 4 years ago

Add initial support for UEFI installs to FreeNAS This updates grub2-pcbsd with some needed kernel settings (Vt) and updates the sysutils/grub2-efi with a later version. Lastly it updates the installer to determine if we are UEFI booted or not, and DTRT if so. Ticket: #14414 (cherry picked from commit 18d00df28ba13aec779945b2ecbbc85f15df49ad)

History

#1 Updated by Jordan Hubbard over 4 years ago

  • Target version set to 49

#2 Updated by Jakub Klama over 4 years ago

  • Status changed from Unscreened to Screened

#3 Avatar?id=14398&size=24x24 Updated by Kris Moore over 4 years ago

  • Assignee changed from Jakub Klama to Sean Fagan
  • Priority changed from No priority to Important

Sean,

This is something we really should try and get working sooner rather than later. It lets us do more types of FreeNAS installs, plus more interesting installs into bhyve and VMs.

I can fill you in on the gory details on getting it setup, but here's a rough-draft:

- Include grub2-efi package from FreeBSD ports
- Create FAT16 partition instead of bios-boot "newfs_msdos -F 16 ada0p1"
- Mount said msdos partition to /boot/efi
- When doing grub-install use these flags "--efi-directory=/boot/efi --removable --target=x86_64-efi"

#4 Updated by Sean Fagan over 4 years ago

The fact that this is incompatible with the existing system makes it harder to do. (Hm, not imossible. Check for /boot/efi vs /boot/grub, change behaviour based on that. Hm.)

fn10 could go this route, I think.

#5 Avatar?id=14398&size=24x24 Updated by Kris Moore over 4 years ago

This shouldn't be incompatible at all, we support BIOS/EFI on PC-BSD without issue. The grub2-pcbsd scripts have a check in it. When it goes to re-stamp GRUB it always looks at the disk format. If we find a 'bios-boot' partition on adaXp1, then we do BIOS. If we find a EFI partition, then DTRT:

I.E. (This clearly is an EFI installation)

% gpart show ada0
=> 40 976773088 ada0 GPT (466G)
40 204800 1 efi (100M)
204840 968345600 2 freebsd-zfs (462G)
968550440 8192000 3 freebsd-swap (3.9G)
976742440 30688 - free - (15M)

We typically even have the grub2-efi package installed on BIOS systems. Just having that installed doesn't change grub behavior in any way on BIOS systems, unless you manually throw those --target flags into grub-install.

Let me know if you have other blockers specific to FreeNAS though, I'd be curious to see what/why.

#6 Updated by Sean Fagan over 4 years ago

Oh, I see, you only use "--efi-directory=/boot/efi --removable --target=x86_64-efi" during the initial install, not on subsequent updates. Except that we have to install grub on every update, since there is not a way to tell if it's been updated or not.

#7 Avatar?id=14398&size=24x24 Updated by Kris Moore over 4 years ago

Correct, we had that problem on PC-BSD also. The way we do it is have a little extra glue before we run grub-install on upgrades, to check if its EFI. If so, just add those same specific flags again and grub-install will do the rest of the magic.

#8 Updated by Sean Fagan over 4 years ago

sigh. Also complications due to mirroring.

With this approach, at least as I understand it, we can't have a mirrored partition. Currently, we use the freebsd-boot pool, so if it's mirrored, so is the /boot/grub.

#9 Updated by Sean Fagan over 4 years ago

Unless /boot/efi doesn't need to be mounted all the time, in which case it's pretty easy to handle then -- only mount it when installing grub, and do that for each disk.

#10 Avatar?id=14398&size=24x24 Updated by Kris Moore over 4 years ago

Yea, /boot/efi does not need to be mounted, except when doing the grub-install process. (It copies a new bootx64.efi file into there)

So you could do that before running grub-install on any disk.

#11 Updated by Sean Fagan over 4 years ago

Bah, FAT16 needs a 4mbyte+ partition, minimum.

#12 Updated by Sean Fagan over 4 years ago

And it does not work in VMWare Fusion.

That was creating a 32m FAT16 partition.

#13 Avatar?id=14398&size=24x24 Updated by Kris Moore over 4 years ago

Yea, EFI expects larger partition sizes. What error do you get in vmware fusion? And can you attach the specific commands used to do the setup? Want to compare what I have here.

#14 Updated by Sean Fagan over 4 years ago

Simply did not recognize the drive as bootable.

gpart add -t bios-boot -s 32m -i 1 ${_disk}
newfs_msdos -F 16 /dev/${_disk}p1

mkdir -p ${_mnt}/boot/efi
mount -t msdosfs /dev/${_disk}p1 /boot/efi
chroot ${_mnt} /usr/local/sbin/grub-install --modules='zfs part_gpt' --efi-directory=/boot/efi --removable --target=x86_64-efi /dev/${_disk}
umount ${_mnt}/boot/efi

#15 Avatar?id=14398&size=24x24 Updated by Kris Moore over 4 years ago

Ok, you are using the wrong partition type there:

gpart add -s 32M -t efi -i 1 ${_disk}

Give that a whirl.

#16 Updated by Sean Fagan over 4 years ago

Unless I am missing something, it does not appear to be possible to make a freenas-bootable device that is both BIOS and UEFI compatible. (Looks like we can make a single ISO image.)

That's a fairly significant problem, for several reasons.

I need to figure out how to get a UEFI-booting VM under VMWare. Or get a UEFI system. (Hm. I wonder if a Mac would work. I can get a spare one of those easily enough.)

#17 Avatar?id=14398&size=24x24 Updated by Kris Moore over 4 years ago

  • Assignee changed from Sean Fagan to Kris Moore

Sean,

If you don't mind, I'll take a crack at this one. Since I did it once for PC-BSD anyway, might still be fresh enough in memory to hack on ;)

#18 Avatar?id=14398&size=24x24 Updated by Kris Moore over 4 years ago

  • Status changed from Screened to 19

#19 Updated by Sean Fagan over 4 years ago

This doesn't include support for updating grub in an update, btw.

#20 Avatar?id=14398&size=24x24 Updated by Kris Moore over 4 years ago

Sean,

Correct. I was going to open a ticket for that next, and one for when you replace a drive in the boot pool. Could I do that and assign to you, now that we have something to play with?

#21 Updated by Sean Fagan over 4 years ago

I still have no idea how to test it, that's been the problem.

Fortunately, the update won't destroy the existing grub in this case (I think :)).

Hm. Also, no, it's going to require changes to the update code, so can't just be done in the post-upgrade script. Darn it.

#22 Updated by Sean Fagan over 4 years ago

Wait, no. The efi partition only has to be mounted when grub-install is run. So it can be done in the post-upgrade script.

#23 Avatar?id=14398&size=24x24 Updated by Kris Moore over 4 years ago

  • Status changed from 19 to Resolved

Seems to be working through a couple of fresh EFI installs here. Feel free to open other tickets if / when problems found.

#24 Updated by Sean Fagan over 4 years ago

This must be done in 10 as well.

#25 Avatar?id=14398&size=24x24 Updated by Kris Moore over 4 years ago

  • Status changed from Resolved to Ready For Release

#26 Updated by Michael Dexter over 4 years ago

I have tested this on a ThinkPad, bhyve and a non-UEFI system and all behave as expected.

To state the obvious, the FreeBSD loader now supports boot environments, paving the way to remove GRUB from the mix. I have a similar ticket for this.

#27 Updated by Jordan Hubbard over 4 years ago

To state the equally obvious, "supporting boot environments" will have to also encompass the current GRUB UI, which is quite easy for novice FreeNAS users to use (they are also not typically OS experts or even OS fans), particularly given that their goal is to "select a previous update" (which is how they think of BEs) from a menu with obvious UI travel keys, not have to interact with obscure boot loader options and become FreeBSD users. FreeNAS is an appliance, not a general purpose OS, and is only becoming more so over time (this is a good thing).

FWIW, is also think that most FreeBSD users would prefer a nice UI for selecting a previous BE, the "beastie menu" being pretty retro and a frequent topic of derision from Linux users, so if this gets promoted more widely as an easy-to-use option for FreeBSD (with some escape key for escaping down to the lower layers as needed) then I can't imagine it getting a lot of push-back if we were to both implement such a thing (Kris?) and try to upstream it.

#29 Avatar?id=14398&size=24x24 Updated by Kris Moore about 3 years ago

  • Target version changed from 49 to N/A

#30 Updated by Dru Lavigne almost 3 years ago

  • Status changed from Ready For Release to Resolved

Also available in: Atom PDF