summaryrefslogtreecommitdiff
path: root/proxy.sh
diff options
context:
space:
mode:
authorJulia Kreger <juliaashleykreger@gmail.com>2022-02-25 12:18:39 -0800
committerRiccardo Pittau <elfosardo@gmail.com>2022-06-07 09:04:48 +0000
commita73fe97cea7cd9c42d081cc5ec6c6b36a79eb22e (patch)
tree26156a3efce56eaeb9bf31289a37c8c15cb67228 /proxy.sh
parente880cb30a9c25641486c7a2cda83dd75d5789868 (diff)
downloadironic-python-agent-a73fe97cea7cd9c42d081cc5ec6c6b36a79eb22e.tar.gz
Create fstab entry with appropriate label
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 (cherry picked from commit 99ca1086dbfc7b6e41cf800b0bd899565e2e8922) (cherry picked from commit c69ea032fe8ab81e459fb44f846f440e7a2c8922)
Diffstat (limited to 'proxy.sh')
0 files changed, 0 insertions, 0 deletions