99ca1086db
Depending on the how the stars align with partition images being written to a remote system, we *may* end up with *either* a Partition UUID value, or a Partition's UUID value. Which are distinctly different. This is becasue the value, when collected as a result of writing an image to disk *falls* back and passes the value to enable partition discovery and matching. Later on, when we realized we ought to create an fstab entry, we blindly re-used the value thinking it was, indeed, always a Partition's UUID and not the Partition UUID. Obviously, the label type is quite explicit, either UUID or PARTUUID respectively, when initial ramdisk utilities such as dracut are searching and mounting filesystems. Adds capability to identify the correct label to utilize based upon the current state of the block devices on disk. Granted, we are likely only exposed to this because of IO race conditions under high concurrecy load operations. Normally this would only be seen on test VMs, but systems being backed by a Storage Area Network *can* exibit the same IO race conditions as virtual machines. Change-Id: I953c936cbf8fad889108cbf4e50b1a15f511b38c Resolves: rhbz#2058717 Story: #2009881 Task: 44623
11 lines
520 B
YAML
11 lines
520 B
YAML
---
|
|
fixes:
|
|
- |
|
|
Fixes handling of a Partition UUID being returned instead of a
|
|
Partition's UUID when the OS may not return the Partition's UUID in time.
|
|
These two fields are typically referred to as PARTUUID and UUID,
|
|
respectively. Often these sorts of issues arise under heavy IO load.
|
|
We now scan, and identify which "UUID" we identified, and update
|
|
a Linux fstab entry appropriately. For more information, please see
|
|
`story #2009881 <https://storyboard.openstack.org/#!/story/2009881>`_.
|