builder: add EFI-specific boot values #100
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
e784b45 to
960069b
Compare
3a24d74 to
30e3193
Compare
30e3193 to
e86b659
Compare
nywilken
reviewed
Nov 2, 2022
Comment on lines
+357
to
+342
| // NOTE: when booting a UEFI machine with Secure Boot enabled, this has | ||
| // to be a q35 derivative. |
There was a problem hiding this comment.
Should there be some validation or warning in Prepare to let the user know that they have enabled EFI with a non-q35 derivative machine type?
I'm not sure if this is a simple check. So I would be cool if you tell me there are too many combinations to validate; its better for the user to see the failure 😉
There was a problem hiding this comment.
EFI on a non-q35 machine is fine, the problem is Secure-Boot, which is only supported on q35 machines (can't fine the docs to refer to that, but other machine types AFAIK will result in a blank screen).
Not sure we can reliably validate that, maybe by checking the name for the OVMF_*fd, but that's a stretch as a user might rename them, and the check will not bump the error.
e86b659 to
67dd48e
Compare
BIOS and (U)EFI are two standard for booting machines. BIOS being legacy, which is still supported by several OSes, but is getting phased out little-by-little, in favour of EFI. EFI requires several components to boot a machine: a GPT-backed disk, a firmware to load the bootloaders, and efivars to keep persistent data in NVRAM between boots. This is translated in qemu as a collection of a code file that contains the firmware, and a vars file that holds a template efivars, which may have some keys or properties setup. This commit adds new configuration values to enable this. At its simplest, this might be just enabling `efi_enabled` to boot with EFI support. In practice, YMMV, as some protocols (typically Secure Boot) will require more setup before being able to get something to work as expected. The EFI CODE and VARS files are automatically loaded from /usr/share/OVMF if available, otherwise they need to be specified manually. The docs for Qemu are updated to reflect these changes.
67dd48e to
e092632
Compare
LKHN
added a commit
to LKHN/cloud-images
that referenced
this pull request
Dec 5, 2022
In 1.0.7 - hashicorp/packer-plugin-qemu#100 version of the QEMU Packer plugin, it's possible to boot and build images in UEFI and with Secure Boot enabled Signed-off-by: Elkhan Mammadli <elkhan.mammadli@protonmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
BIOS and (U)EFI are two standard for booting machines. BIOS being legacy, which is still supported by several OSes, but is getting phased out little-by-little, in favour of EFI.
EFI requires several components to boot a machine: a GPT-backed disk, a firmware to load the bootloaders, and efivars to keep persistent data in NVRAM between boots.
This is translated in qemu as a collection of a code file that contains the firmware, and a vars file that holds a template efivars, which may have some keys or properties setup.
This commit adds new configuration values to enable this. At its simplest, this might be just enabling
efi_enabledto boot with EFI support.In practice, YMMV, as some protocols (typically Secure Boot) will require more setup before being able to get something to work as expected.
The EFI CODE and VARS files are automatically loaded from /usr/share/OVMF if available, otherwise they need to be specified manually.
The docs for Qemu are updated to reflect these changes.
Related to: #97