Bug 1320318
| Summary: | The ironic pxe_ilo driver is using uefi boot_mode by default but uefi is not configured by the undercloud installation | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | David Hill <dhill> | ||||
| Component: | instack-undercloud | Assignee: | Dmitry Tantsur <dtantsur> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Raviv Bar-Tal <rbartal> | ||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 7.0 (Kilo) | CC: | asimonel, dhill, dtantsur, hbrock, jcoufal, jean-francois.bibeau, jschluet, jslagle, lbezdick, lmartins, mburns, mkovacik, mlopes, nlevinki, rhel-osp-director-maint, vaggarwa | ||||
| Target Milestone: | rc | Keywords: | Triaged | ||||
| Target Release: | 10.0 (Newton) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | python-tripleoclient-5.2.0-1.el7ost instack-undercloud-5.1.0-2.el7ost | Doc Type: | Bug Fix | ||||
| Doc Text: |
Previously, the `pxe_ilo` Bare Metal Service (ironic) driver would automatically switch to UEFI boot when it detected UEFI-capable hardware, even though the environment might not support UEFI.
Consequently, the deployment process failed with pxe_ilo drivers when an environment did not support UEFI.
With this update, the pxe_ilo driver defaults to BIOS boot mode, and a deployment using pxe_ilo now works out of the box, regardless of whether UEFI is configured properly.
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2016-12-14 15:29:13 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: | |||||||
| Attachments: |
|
||||||
|
Description
David Hill
2016-03-22 20:19:47 UTC
This bug did not make the OSP 8.0 release. It is being deferred to OSP 10. Hi @David, Thanks for the report. I've opened a bug upstream against the iLO driver's [0] behavior of trying to magically figure out what boot mode it should use by default. Unfortunately, it will up to the iLO developers to accept it or not for their driver. For OSP, I think we should explicitly set the boot mode when it enroll the nodes and create the flavors according to the user configuration. [0] https://bugs.launchpad.net/ironic/+bug/1604002 Hi David, One of the iLO devs replied to the bug upstream asking few questions [0], one of the question is about the hardware. Is the machine an iLO Gen 9 ? [0] https://bugs.launchpad.net/ironic/+bug/1604002/comments/2 Hello! Starting with OSP10, we're providing UEFI-capable unddercloud by default, so this should no longer be an issue. Additionally, we provide a new configuration option for tweaking the default. It can be set to 'bios' via puppet variable ironic::drivers::ilo::default_boot_mode. Created attachment 1213055 [details]
Ironic provides the conf option to change the behaviour of iLO driver
Ironic iLO driver seems to contain the patch.
However I'm unsure about how to propagate the "iLO.default_boot_mode" to the relevant undercloud installation mechanism. Where would be the bet place to set the "ironic::drivers::ilo::default_boot_mode" variable before calling the "openstack undercloud install" command?
I'm reopening this issue. We have UEFI support currently broken in OSP 10, so we should change the default as well as described in comment 11. UEFI is currently supported by default in osp10, so booting uefi node is not an issue any more. please note: currently triple-o blocks inspector from setting the boot_mode:uefi/bios automatically so you may need to set the parameter or enable boot_mode=true in inspector.conf before inspection default setting bug for triple-o https://bugs.launchpad.net/tripleo/+bug/1639858 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-2948.html |