It's interesting that CORE_BOOT_UNENCRYPTED is the first element of allowed -- I guess this is another symptom of bug 2033244.
I'm also not surprised that this install did not boot under BIOS -- we should probably not allow it on a BIOS system (but the client is still being weird)
Those logs are from an *unencrypted* core boot classic / hybrid install, which isn't supposed to be possible!
See the capability= <GuidedCapabili ty.CORE_ BOOT_UNENCRYPTE D: 7> bit in:
GuidedChoiceV2( target= GuidedStorageTa rgetReformat( disk_id= 'disk-vda' , allowed= [<GuidedCapabil ity.CORE_ BOOT_UNENCRYPTE D: 7>, <GuidedCapabili ty.DIRECT: 2>, <GuidedCapabili ty.LVM: 3>, <GuidedCapabili ty.LVM_ LUKS: 4>, <GuidedCapabili ty.ZFS: 5>], disallowed= [GuidedDisallow edCapability( capability= <GuidedCapabili ty.CORE_ BOOT_ENCRYPTED: 6>, reason= <GuidedDisallow edCapabilityRea son.CORE_ BOOT_ENCRYPTION _UNAVAILABLE: 2>, message='not encrypting device storage as checking TPM gave: not a supported EFI system')]), capability= <GuidedCapabili ty.CORE_ BOOT_UNENCRYPTE D: 7>, sizing_ policy= <SizingPolicy. ALL: 2>, reset_partition =False)
It's interesting that CORE_BOOT_ UNENCRYPTED is the first element of allowed -- I guess this is another symptom of bug 2033244.
I'm also not surprised that this install did not boot under BIOS -- we should probably not allow it on a BIOS system (but the client is still being weird)