Since we will slip final freeze of 21.10 not yet having that
confirmation we should start preparing the SRU template which we will
need later on anyway. Just to pre-eliminate any later stalls.
For that the biggest missing piece for me is the "how to reproduce" you said it
affects customization via cloud-init on vmware guests.
It wasn't stated how a setup for repro for would look like yet.
I currently lack a system to test this, so I've drafted steps based on
the code but would like to ask you @John to revise them. Mission - as
always - is to keep them as simple as possible which e.g. implies to -
if possible - not use advanced VMWare host configurations.
---
But from studying the code I see a few things that make me wonder which
exact config is needed to reach the code that is affected by this. Here
from ds-identify code.
991 dscheck_OVF() {
992 check_seed_dir ovf ovf-env.xml && return "${DS_FOUND}"
If an image was built placing data in /var/lib/cloud/seed/ovf/...
That should not happen in a fresh clear environment and will likely be stepped
over.
994 [ "${DI_VIRT}" = "none" ] && return ${DS_NOT_FOUND}
In a systemd I'd expect systemd to already identify vmware via
systemd-detect-virt and due to that it would return TRUE here?
Did you only see this in odd guest setups because right now I wonder how it
ever gets to the further steps in a "normal" case?
996 # Azure provides ovf. Skip false positive by dis-allowing.
997 is_azure_chassis && return $DS_NOT_FOUND
Not important in our cases as we are not talking about Azure, will be
stepped over
999 ovf_vmware_transport_guestinfo && return "${DS_FOUND}"
If here vmware-rpctool "info-get guestinfo.ovfEnv" gets content it
returns with DS_FOUND
1001 has_ovf_cdrom && return "${DS_FOUND}"
If cloud-init config data is presented via cdrom it returns here.
1003 ovf_vmware_guest_customization && return "${DS_FOUND}"
Only if it stepped over all of the above, no config CDrom, no data via
vmware-rpctool, not even systemd-detect-virt finding vmware - only then
the code of "ovf_vmware_guest_customization" which has the issue with
the new path will be ran.
1005 return ${DS_NOT_FOUND}
This is the final, nothing found return
---
WIP Steps to reproduce to improve on
1. set up a VMWare based Ubuntu guest
1.1 does the user or the tooling have to set disable_vmware_customization ?
something like
echo
"search,found=all,maybe=all,notfound=disabled,disable_vmware_customization=false"
| sudo tee /etc/cloud/ds-identify.cfg
1.2 do any other options/customizations matter?
2. in the Ubuntu guest run ds-identify and check if the output detected
vmware correctly
2.1 $ sudo /usr/lib/cloud-init/ds-identify
2.2 $ cat /run/cloud-init/cloud.cfg
In the good case this looks like ???
In the bad case it fails to detect VMware and looks like ???
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1944946
Title:
Path of open-vm-tools libdeployPkgPlugin.so is now multi-arch
compliant breaking cloud-init
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1944946/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
