diff options
author | Julia Kreger <juliaashleykreger@gmail.com> | 2022-02-25 12:18:39 -0800 |
---|---|---|
committer | Riccardo Pittau <elfosardo@gmail.com> | 2022-06-07 09:04:48 +0000 |
commit | a73fe97cea7cd9c42d081cc5ec6c6b36a79eb22e (patch) | |
tree | 26156a3efce56eaeb9bf31289a37c8c15cb67228 /proxy.sh | |
parent | e880cb30a9c25641486c7a2cda83dd75d5789868 (diff) | |
download | ironic-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