Fix UTF-16 result handling for efibootmgrstable/wallaby

The tl;dr is that UEFI NVRAM is in encoded
in UTF-16, and when we run the efibootmgr command,
we can get unicode characters back.

Except we previously were forcing everything to be
treated as UTF-8 due to the way oslo.concurrency's
processutils module works.

This could be observed with UTF character 0x00FF
which raises up a nice exception when we try to
decode it.

Anyhow! while fixing handling of this, we discovered
we could get basically the cruft out of the NVRAM,
by getting what was most likey a truncated string
out of our own test VMs. As such, we need to also
permit decoding to be tollerant of failures.
This could be binary data or as simple as flipped
bits which get interpretted invalid characters.
As such, we have introduced such data into one of our
tests involving UEFI record de-duplication.

NOTE: One of the unit tests from the stable/xena backport
were removed, as software raid was still in-flight at the
end of Wallaby.

Closes-Bug: 2015602
Change-Id: I006535bf124379ed65443c7b283bc99ecc95568b
(cherry picked from commit 76accfb880474445a5dcb07825889123b3dd0237)
(cherry picked from commit 9f84c8b3d1fa0e08bf1f799f37a11698f8da07a4)
(cherry picked from commit d77424d7315e24390d6b159eab8dd9b3d4c56942)

1 files changed, 9 insertions, 0 deletions

diff --git a/releasenotes/notes/fixes-efibootmgr-character-encoding-19e531ba694824c1.yaml b/releasenotes/notes/fixes-efibootmgr-character-encoding-19e531ba694824c1.yaml
new file mode 100644
index 00000000..b4c3270c
--- /dev/null
+++ b/releasenotes/notes/fixes-efibootmgr-character-encoding-19e531ba694824c1.yaml
@@ -0,0 +1,9 @@
+---
+fixes:
+  - |
+    Fixes UEFI NVRAM record handling with efibootmgr so we can accept and
+    handle UTF-16 encoded data which is to be expected in UEFI NVRAM as
+    the records are UTF-16 encoded.
+  - |
+    Fixes handling of UEFI NVRAM records to allow for unexpected characters
+    in the response, so it is non-fatal to Ironic.