Reno was assuming all tags ending in -eol represented an old, EOL'd stable branch. That's not true for Ironic projects which have bugfix branches. Update the regexp to exclude those branches. Co-Authored-By: Adam McArthur <adam@mcaq.me> Change-Id: I265969ab40a98a02962c2fc8460b6519ab576f99 (cherry picked from commit f8fc7e52f36de5c3515e60f5d2e6347a538a80d8)
Also disable software raid which fails on standalone since it was a newer test, and only partially in place in Train. Change-Id: I1e7a3b3c9ded13b10002bb47e98d4a7b486e1dd4
Change-Id: I7cedd5df1836f6c571b84fc8418bf5608bcebf9d
Re-read the partition table with 'partx -a', rather than 'partx -u'. This should fix an timing issue where the bootloader installation fails to mount the EFI partition from a whole disk image since it is not yet aware of the new partitions (observed with both, the iscsi and the direct deploy interface). Change-Id: If5da3075e813ae01df3decf8f0647aba111b0515 (cherry picked from commit dc8c1f16f9a00e2bff21612d1a9cf0ea0f3addf0) (cherry picked from commit ab3e8a75badf2719602b2416af9e3c19d7511c79) (cherry picked from commit 74389394001d3fd436ef963d60c93c2b3ee09f0d)
I accidently put colons on the test data and remembered taking the colon character out of the regex I was working on, but apparently left it in, and accounted for the active entry indicator flag which appears to have inconsistent support across vendors. The regex has been fixed, and a test added from a Lenovo SR650 which has some additional string entry data in the UEFI output which may separate entries. Change-Id: I1f67b0fb1f645fa82e98bd7c7bba3ffc7755cc74 (cherry picked from commit e10f052c06c03016b0ff4d9c1f3191c79fc50a1a) (cherry picked from commit 87a30ff4fa93e710efa2f9eeb227c779d40c16af) (cherry picked from commit 25f89e4d8859ec1a3e811c3d916cf49d603754fc) (cherry picked from commit 3ecda566ef1abe01f7acf0adaf63d592e4520a6d)
Some firmware seems to take an objection with EFI nvram entries being deleted after one is added, resulting in the entire entry table being reset to the last known good state. This is problematic, as ultimately deployments can time out if we previously booted with Networking, and the machine, while commanded to do other wise, reboots back to networking regardless. We will now delete entries first, before proceeding. Additionally, for general use, this pattern may serve the community better by avoiding cases where we would have previously just relied upon efibootmgr[0] to warn us of duplicate entries. [0]: https://github.com/rhboot/efibootmgr/blob/103aa22ece98f09fe3ea2a0c83988f0ee2d0e5a8/src/efibootmgr.c#L228 Change-Id: Ib61a7100a059e79a8b0901fd8f46b9bc41d657dc Story: 2009649 Task: 43808 (cherry picked from commit 67eddfa7e3fedbb530045f5b43a2c89db832fa2a) (cherry picked from commit 33b39705a50513c5af411216b48e2a6f6ac9ab14) (cherry picked from commit 8fca1457399ac7892427fac1b9ab74a4ac653f05) (cherry picked from commit 47ac40a7f943d0ce6e58f43330a73ac144c23aa1) (cherry picked from commit bb5b1ba8de8464dc56f4f6ceacfdbb276fac4a46)
When debugging boot manager problems it can be advantageous to see all the full entries rather then just their labels. Depends-On: https://review.opendev.org/c/openstack/ironic/+/818735 Change-Id: I6a1bb78acaf5a4284727bdf533d4be6db2099f50 (cherry picked from commit caf695f70ab366498b46cb6f07f6751369c67e30) (cherry picked from commit 9753b61a51008da4f0b948b0c89665b762eb95c4) (cherry picked from commit 750934a20794efdcfe8340eec75996466c4c7665) (cherry picked from commit 76576ad73f85851d803d436ee7a7ca563606ecfa)
When the support to load the default bootloader configuration was backported to stable train, I modified it to pass python2 unit tests as well as ultimately attempt to be compatible. It might have actually worked! What did not work for Python3 when the UTF-16 codepoint delimiter file was encountered in a production case. This passed CI originally just fine, however Ubuntu images do not have the delimiter codepoint, where as RHEL images *do* have a UTF-16 delimiter at the start of the file. On python3, with the python2 compatible code, the file was being opened as ascii or UTF-8, which we know as the same rule applies for both. All code points must be <0xFF. This resulted in the file open itself to fail, as encoding support differs between Python2 and Python3. What this patch does now is separately handle the case of if python2, to use the new preview python3 io subsystem previewed in python2 to open the file properly, and present the UTF-16 encoded results. This issue was identified in RHOSP testing with python 3.6, with partition images where the deployment would fail with reporting that the ascii codec could not decode 0xFF which indicates that the contents are being handled as something other than utf-16, and it is hitting a constraint in string handling in Python where ascii and utf-8 character code points are expected to always be <0xFF. Story: 2009020 Task: 42742 rhbz#1977417 Change-Id: I08664c2b3900448633837e40098a0ff9f0bd65f7
Due to a regression in lshw introduced by https://github.com/lyonel/lshw/pull/60, there are some versions in the wild that do not return sizes for memory banks <32GiB. In those cases, work around the problem by looking at the top-level size (if available) to find the total size. Previously we assumed that we only needed the top-level size when there was no list of memory banks. The issue is fixed upstream by https://github.com/lyonel/lshw/pull/65, but the erroneous patch is still present in the lshw-B.02.19.2-5.el8 package in CentOS 8.4 and 8.5. Note from Backport to Victoria branch: The stable test data was moved sometime during the Wallaby development cycle to a separate file, where as in Victoria and earlier, it is based in the test file itself. The required content was moved into the test file in line with where it was in the later versions. Change-Id: I6eb5981d28b9ae368239af0c1d0ec32ff79d95b3 Story: #2008865 Task: 42395 (cherry picked from commit ed791d97786f4ed37bf7b9f18eac8e2af46c3766) (cherry picked from commit bae3aec172df5b6ca9d609f29ea9feb9f6d11f13) (cherry picked from commit 97ce08d039099f569c48a2348c784e71e3693829) (cherry picked from commit 746f65bd8481aac32abb12768590e809697449e4)