Fix UTF-16 result handling for efibootmgrstable/yoga

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.

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

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.