-
Notifications
You must be signed in to change notification settings - Fork 39
UEFI
I managed to switch the OpenXT disk to GPT and re-install grub to get OpenXT to boot.
The next step is to switch to UEFI.
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/sdavgcfgrestore --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".
-
pvdisplayremember 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)>
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
This page is a GRUB gold mine:
https://wiki.archlinux.org/index.php/GRUB