76accfb880
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
10 lines
332 B
YAML
10 lines
332 B
YAML
---
|
|
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.
|