GPT partition names are basically free-text fields but the udev PARTNAME
field ends up butchered by the kernel when it contains characters
outside the ASCII range.
When using pyudev, the values are all expected to be decodable using the
system's default encoding.
In curtin, it can result in a crash when iterating over all the
properties of a block device, that are mapped by pyudev.
To work around the issue, we now stop iterating over all the values. We
iterate over the keys and only access the value if we need it.
block_meta_v2: make GPT partition name support more robust
In some cases, the sfdisk script will include GPT partition names. GPT
partition names support characters outside the ASCII range (they are
stored in UTF-16 in the GPT metadata). Therefore, it is currently a
wrong assumption that the sfdisk input is always valid ASCII.
Furthermore, we inject the name straight inside the sfdisk input script
(surrounded with double quotes)..
This can result in various problems if the name contains a '"' character
(the sfdisk field delimiter) or other characters such as '\\'.
Fixed by converting all the characters of the partition names into their
utf-8 \x notation. sfdisk natively supports reading this format. This
will have a slight implact on the readability of the sfdisk script, but
should make it way more robust.
tests: make random_string a staticmethod instead of classmethod
CiTestCase.random_string was decorated with @classmethod.
I guess the purpose was to make the function usable without a CiTestCase
instance. However, @classmethod is used when a function should return an
instance of the class.
This is not what we want. @staticmethod is the right decorator in this
context.
block_meta_v2: don't solely expect flag='logical' for logical partitions
Most of the time, a logical partition has its flag set to 'local'.
However, it some cases, it can also have flag set to 'swap', 'boot' and
possibly other values.
To determine if a partition is actually logical on a DOS partition
table, we need to check the partition number.
block-meta: fix failed disk lookup when WWN includes extension
curtin's storage config extracts the WWN of a disk from one of the
following udev variables:
* ID_WWN_WITH_EXTENSION (preferred)
* ID_WWN
However, when trying to look the disk up later in the block-meta code,
curtin only tries to match the WWN value against the ID_WWN variable
(and another variable related to DM multipath).
This means that the disk can not be be found just based on the wwn if
the ID_WWN and ID_WWN_WITH_EXTENSION variables don't hold the same
value.
In the past, that was often okay because other fields (such as disk path
or serial) would still make the disk lookup succeed.
However, the following patch introduced a restriction. In v2, all fields
specified must now match for the disk lookup to be successful:
8c5f87ed block_meta: all fields on a disk action must match with v2 config
Fixed by matching against the ID_WWN_WITH_EXTENSION (preferred) and then
ID_WWN.
