Bug 1903652
| Summary: | DIB_BLOCK_DEVICE_CONFIG provide example for UEFI partitioning | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Andreas Karis <akaris> |
| Component: | documentation | Assignee: | fallen |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | RHOS Documentation Team <rhos-docs> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 16.1 (Train) | CC: | amcleod, apevec, dmacpher, fallen, jschluet, lyarwood, mariel, pweeks, sbaker |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-05-05 07:48:10 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1915368 | ||
|
Description
Andreas Karis
2020-12-02 15:10:47 UTC
AFAIK, Ian is the only one supporting DIB...moving to PCD. I would say the best example of this is tripleo; particularly the config at [1]. You really just need that and "block-device-efi" element. https://opendev.org/openstack/tripleo-image-elements/src/branch/master/elements/overcloud-partition-uefi/block-device-default.yaml It should be documented, though. I'm assigning this to the documentation component. Lets use this bug to ensure following chapter 23 results in a valid UEFI image. It will need the following changes:
- 23.6[1] needs a second example for a customized DIB_BLOCK_DEVICE_CONFIG which is for building UEFI images. The content of the UEFI version of DIB_BLOCK_DEVICE_CONFIG needs to be the same as what is in the overcloud-partition-uefi element[2].
- 23.7.1 The second argument of the 'cp' command can just be /home/stack/, so the file keeps its original name when it is overcloud-hardened-images-uefi-python3.yaml
- 23.8 The image name for the uefi image is overcloud-hardened-uefi-full, maybe there should be a new block showing the uefi version of the create command, which would be:
# openstack overcloud image build \
--image-name overcloud-hardened-uefi-full \
--config-file /home/stack/overcloud-hardened-images-uefi-python3-custom.yaml \
--config-file /usr/share/openstack-tripleo-common/image-yaml/overcloud-hardened-images-uefi-rhel8.yaml
- 23.9.1 the image name is different so the mv command would be:
# mv overcloud-hardened-uefi-full.qcow2 ~/images/overcloud-full.qcow2
If we did some diskimage-builder backports to 16.x then we could transform this chapter to be UEFI only, because the backports will allow the uefi image boot to legacy bios as well. We'll need to do these backports anyway because the next promotion of grub2 is going to break UEFI image builds :)
[1] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html-single/director_installation_and_usage/index#modifying-the-partitioning-schema
[2] https://opendev.org/openstack/tripleo-image-elements/raw/branch/master/elements/overcloud-partition-uefi/block-device-default.yaml
Hey @dmacpher @amcleod Would any of you be able to look over this ticket? Many thanks, Vlada The director guide was updated today with information concerning "Modifying the partition schema" including a UEFI example. https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/director_installation_and_usage/index#modifying-the-partitioning-schema Can you please take a look and let me know if that fills all your needs or is there still some information missing? I switched teams twice since and I'm not even in support any more. So I won't be able to provide any feedback on this :-/ Looks good, I think this can be closed now. This section will need a complete rewrite for 17.0 since the default image is now overcloud-hardened-uefi-full. There may not be any need for the deployer to ever build their own image from scratch. Published. The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days |