DIB - cleaning upon failure is incomplet for overcloud-hardened-uefi-full
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
tripleo |
Triaged
|
Medium
|
Steve Baker |
Bug Description
Hello,
It seems the cleaning upon failure for the hardened-uefi-full OC image isn't correct:
after the cleaning, I still see dangling "vg" and its associated physical volume (usually pointing to some loop device).
This dangling "vg" prevents any new run on the same host until we manually clean things up, since the name is fixed.
By the way, I think we shouldn't hardcode "vg" as it's a generic enough name to already exist on the node that is building the image. We probably should make a derivation based on the machin-id (take the N first chars) so that we have something more random/generic.
The "incriminated" files are apparently:
diskimage_
diskimage_
Apparently, that dangling volume is also leading to a second issue when it first fails to build the image, where something is still mounted somewhere (sub-directory I'd say) in the temporary workspace/
So, basically, the issues are:
- generic name for the volume group: we should be smarter
- lack of actual cleaning, leading to multiple issues, among them dangling "vg" still present on the system with its associated physical volume
- this lack of cleaning is probably explaining why I end up with many, many "loop" devices in /dev/mapper
Cheers,
C.
As a side note, we seem to miss call to "dmsetup remove /dev/mapper/ loopXpY" in order to get a clean status at the end.
If we don't do that, we keep dangling "partitions" in /dev/mapper, and the /dev/loopX is still binded to the /image0.raw - this may explain some of the issues. Note that this apparently happens only upon a build failure.