Not possible to set partition type on GPT partitions, preventing firmware boot
The UEFI specifications require the EFI system partition to have a specific "GPT type" GUID. There is not currently a mechanism which allows this in the partitioning steps that vmdb2 allow. Some (many?) UEFI firmwares will not boot from GPT "EFI System" partitions which lack the correct type GUID.
A similar problem exists with GPT Bios Boot Partitions (which can be used to host the BIOS version of grub's stage2 component so that grub can boot from GPT disks on "legacy BIOS" systems by providing a reserved area for grub or other boot loaders).
references:
https://en.wikipedia.org/wiki/EFI_system_partition
https://wiki.archlinux.org/index.php/Parted#UEFI/GPT_examples
e.g. this vmdb input file:
steps:
- mkimg: "{{ output }}"
size: 6G
- mklabel: gpt
device: "{{ output }}"
- mkpart: '"BIOS Boot"'
device: "{{ output }}"
fs_type: fat32
start: 34s
end: 2047s
tag: biosboot
- mkpart: "EFI"
device: "{{ output }}"
start: 2048s
end: 200M
tag: esp
- mkpart: root
device: "{{ output }}"
start: 200M
end: 100%
tag: root
- kpartx: "{{ output }}"
- mkfs: fat32
partition: esp
- mkfs: ext4
partition: root
Produces this partition table:
gdisk -l test4.img
GPT fdisk (gdisk) version 1.0.3
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk test4.img: 12582912 sectors, 6.0 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): D68C5C24-D744-40A0-9CA0-FFAE4F2D6346
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 12582878
Partitions will be aligned on 2-sector boundaries
Total free space is 2015 sectors (1007.5 KiB)
Number Start (sector) End (sector) Size Code Name
1 34 2047 1007.0 KiB 8300 BIOS Boot
2 2048 391167 190.0 MiB 8300 EFI
3 391168 12580863 5.8 GiB 8300 root
Note the "Code" column corresponds to a gdisk-specific coding which corresponds to the GPT GUID "0FC63DAF-8483-4772-8E79-3D69D8477DE4".
Here is the parted list output for this image file:
Disk /home/tim/work/latitude/test4.img: 6442MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 17.4kB 1049kB 1031kB BIOS Boot
2 1049kB 200MB 199MB fat32 EFI
3 200MB 6441MB 6241MB ext4 root
A standards compliant partition table could be created like this:
sgdisk --zap-all --set-alignment=1 --new=0:34:2047 --change-name=0:biosboot --typecode=0:ef02 --set-alignment=2048 --new=0:0:+200M --change-name=0:EFI --typecode=0:ef00 --attributes=0:set:2 --new=0:0:0 --change-name=0:root test3.img
result:
gdisk -l test3.img
GPT fdisk (gdisk) version 1.0.3
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk test3.img: 12582912 sectors, 6.0 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): BFA3857C-D1B9-4269-9812-9752F4070220
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 12582878
Partitions will be aligned on 2-sector boundaries
Total free space is 0 sectors (0 bytes)
Number Start (sector) End (sector) Size Code Name
1 34 2047 1007.0 KiB EF02 biosboot
2 2048 411647 200.0 MiB EF00 EFI
3 411648 12582878 5.8 GiB 8300 root
parted list output for this disk image:
Disk /home/tim/work/latitude/test3.img: 6442MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 17.4kB 1049kB 1031kB biosboot bios_grub
2 1049kB 211MB 210MB EFI boot, legacy_boot, esp
3 211MB 6442MB 6232MB root
It is also possible to use parted to produce a similar partition table by using the parted set
command, but this command must be run on a separate invocation of parted (it doesn't appear to be possible to set flags at the same time as creating a partition), and set
requires that you specify the partition number (sgdisk
allow you to use the shorthand of partition number 0, which means "the last partition you created"), so this would either need to be inferred or queried using another parted invocation.
Possible routes to fix this would be to use the parted "set" command, or to create an alternative couple of steps to use sgdisk instead. Supporting sgdisk may be simpler for the basic functionality set, and also allow some more advanced functionality that parted does not support (e.g. it only allows a subset of GPT partition type GUIDs to be set).