-
Notifications
You must be signed in to change notification settings - Fork 39
UEFI
DO NOT EDIT: This page has been migrated to Confluence: https://openxt.atlassian.net/wiki/display/DC/UEFI+Notes
- The OpenXT partition can be shrinked to make room for a GPT or new partitions, as there's some unused disk space at the end of the LVM (see Tail-shrink trick.
- The OpenXT disk can be switched to GPT using gdisk once there's enough room.
- After switching to GPT, grub can be reinstalled for UEFI/Legacy BIOS (or even potentially hybrid):
- For legacy BIOS booting, we'll have to create two new partitions. A "BIOS System Partition" (EF00), and a non-LVM /boot partition for at least grub.cfg, as grub doesn't support GPT + LVM (see Grub).
- For UEFI booting, we'll need two partitions as well. An "EFI System Partition" (EF02) and a non-LVM /boot partition. An efi version of Grub will have to be copied to /boot/EFI/BOOT/BOOTX64.EFI, and grub.cfg to /boot/grub/grub.cfg.
- To keep a configuration similar to what we have today, it should be possible to make the new /boot/grub.conf just hop to (lvm/xenclient-boot)/grub/grub.cfg.
Legacy BIOS boot of OpenXT on GPT works fine when using the steps described here. However, UEFI boot requires multiboot2 support (see below).
To be compatible with UEFI firmwares, OpenXT needs a bunch of modifications.
The upgrade can be divided in two steps, first switching to the UEFI partition table, GPT (see next chapter), that is compatible with most legacy BIOSes. Once that's done, we can work on switching to UEFI.
Here are a few components that will need to be updated, in boot order:
The latest version of tboot is supposedly completely compatible with UEFI. The upgrade is in progress.
The latest Xen, Xen 4.5, can be booted from UEFI, but only when built as an efi module.
This is not an option for us, as the UEFI doesn't start Xen in OpenXT. OpenXT uses multiboot to start tboot that will start Xen that will start dom0.
To properly support UEFI, we need multiboot2 support in Xen. There is a patch in the mailing list pending approval for a future version of Xen (4.7?).
The idea for now is to update to Xen 4.5, and add the pending patch to our patchqueue.
The OpenXT installer will have to be modified to create/update the disk to use GPT instead of MBR. More on that in the next section.
For a fresh install, we can just use gdisk instead of fdisk (there's an OpenEmbedded recipe for it upstream), and create a GPT "BIOS boot partition".
The upgrade case is more complicated.
In case of an upgrade, the msdos partition table will have to be replaced by a GPT.
Theoretically, this is very easy, just run gdisk /dev/sda
, write and exit (wq
).
The practical case is more complicated...
GPT uses the beginning and the end of the disk to store metadata. It can vary depending on the original OpenXT install, but gdisk usually finds enough room for itself at the beginning of the disk. However, usually, the OpenXT LVM and partition are configured to span to the very end of the disk, leaving no room for the secondary GPT table.
We need tricks to make room.
Luckily, even when the OpenXT partition starts at the very beginning of the disk, the LVM PV starts 2MB after.
The should move the partition 1MB forward, keeping the LVM PV at the same place on the disk, 1MB after the beginning of the partition:
lvcfgbackup -f /tmp/lv
- Edit /tmp/lv, and around line 25, change the first sector from 2048 to 1024. Also remember the UUID of the PV for pvcreate below.
-
fdisk /dev/sda
u
# Switch to the sector unit
p
# Note the first sector of the OpenXT partition
d 1
n 1
3072
# The previous first sector + 1024
[enter] # The default last sector - Re-probe the disk to load the new layout
pvcreate --restorefile /tmp/lv --uuid <uuid> /dev/sda
vgcfgrestore --file /tmp/lv xenclient
Luckily again, the installer leaves around 1GB at the end of the LVM PV. We can reduce that and use the space for the GPT and the GPT "BIOS boot partition".
-
pvdisplay
remember the PV size minus 200MB pvresize --setphysicalvolumesize <new size> /dev/sda1
-
parted /dev/sda
(This can also probably be done with fdisk, by removing and re-creating a slightly smaller partition, but that seems dangerous.)
u MB
resizepart 1
<new size + 50MB (for safety)>
This section is about installing grub on a GPT (+ LVM) disk.
The only relevant subsection is the UEFI one, but as I found a way to boot in GPT + Legacy BIOS mode, I'm writing about it here.
We currently install grub in a terrible way (see /usr/share/xenclient/install-bootloader
).
We want to install grub the normal way, using grub-install.
Grub can be installed on a GPT. Grub can be installed on an LVM. But grub can't be installed on an GPT LVM. Therefore, we need to create a separate /boot partition, additionally to the BIOS system boot partition (EF02) when booting in legacy BIOS mode.
Once the disk is switched to GPT and the extra partition is created, just run in a chroot:
grub-install --root-directory=<path-to-mounted-boot-partition> /dev/sda
If the legacy BIOS refuses to boot to the disk at this point, try this:
parted /dev/sdX
disk_toggle pmbr_boot
(Warning: That will break UEFI booting!)
Grub doesn't need to be "installed" when using UEFI. The only thing to do is to create an EFI system partition (EF00) on the disk, format it in fat32 (vfat), and copy grub-efi there, in the standard path: /EFI/BOOT/BOOTX64.EFI
.
This page is a GRUB gold mine:
https://wiki.archlinux.org/index.php/GRUB