Bug 1835984
Summary: | [telco] Openshift 4.4.3 boot fails with UEFI mode | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | emahoney |
Component: | Bare Metal Hardware Provisioning | Assignee: | Julia Kreger <jkreger> |
Bare Metal Hardware Provisioning sub component: | ironic | QA Contact: | Raviv Bar-Tal <rbartal> |
Status: | CLOSED WORKSFORME | Docs Contact: | |
Severity: | high | ||
Priority: | high | CC: | akamra, athomas, beth.white, ealcaniz, hpokorny, jkreger, pibanezr, racedoro, stbenjam |
Version: | 4.4 | Keywords: | Reopened, Triaged |
Target Milestone: | --- | ||
Target Release: | 4.6.0 | ||
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: | 2020-06-30 16:16:40 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: |
Description
emahoney
2020-05-14 20:39:54 UTC
Hi, What is the server's brand and model? This sounds similar to BZ1830298. We'll use an entirely different iPXE firmware (snponly.efi) in the fix for that BZ. That uses the built-in UEFI network stack instead of iPXE's set of drivers. If you do see this problem again with snponly.efi, please re-open this bug and provide more details about the hardware being used. *** This bug has been marked as a duplicate of bug 1830298 *** Hm, actually looking at the screenshots closer, it's showing a few different errors. It's worth retrying with the new firmware, but in some screenshots it's failing before you're even in iPXE. ipxe.efi isn't even loaded and things fail much earlier. Later screenshots show "Failed to alloc highmem for files." I'll leave this open for the Ironic folks to take a look. More details about the hardware including types of nics would be helpful as Amit asked for. So adding another question, hardware brand, model and firmware version please.(In reply to Stephen Benjamin from comment #10) > Hm, actually looking at the screenshots closer, it's showing a few different > errors. It's worth retrying with the new firmware, but in some screenshots > it's failing before you're even in iPXE. ipxe.efi isn't even loaded and > things fail much earlier. > > Later screenshots show "Failed to alloc highmem for files." I'll leave this > open for the Ironic folks to take a look. > > More details about the hardware including types of nics would be helpful as > Amit asked for. Specifically we will also need firmware/hardware version of the network devices as reported in the BMC. Here is the latest info from the support case: ~~~~ I was able to reproduce this on a VZ environment with Dell PowerEdge R640 using BIOS 2.4.8 andiDrac Firmware 4.10.10.10. The provisioning NIC is internal, Broadcom Adv. Dual 25Gb Ethernet, controller BIOS version 214.4.32.0, EFI version 214.0.275.0. In the cluster that was failing with UEFI, I had success with snponly.efi instead of ipxe.efi, but I need to test more. ~~~~ Is the new firmware working for you? Does this comment above "In the cluster that was failing with UEFI, I had success with snponly.efi instead of ipxe.efi" mean that this bug can now be closed? It could, of course, be reopened if a reproducable problem were to occur with the use of snponly.efi. That does seem to be the case. I believe we fixed this in our latest 4.4 release, so all we need at this point is confirmation from the filer that it works as expected. The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days |