Furthermore I tried to check this in VMWare Workstation player 16 First of all as I'd expect systemd-detect-virt identified vmware already. $ systemd-detect-virt vmware
The code affected by this issue here is in "ovf_vmware_guest_customization". That is only used in dscheck_OVF. Therefore to streamline the run reduce config to just detect OVF in ds-identify. $ echo "datasource_list: [NoCloud, OVF]" < sudo tee /etc/cloud/cloud.cfg.d/99_test.cfg Running ds-identify in verbose more to check behavior. As expected I see it pass the steps before and reach ovf_vmware_guest_customization. And indeed it fails to detect the pluging and does an early exit. Here with a bit of additional debug inside of ovf_vmware_guest_customization: $ sudo DEBUG_LEVEL=5 DI_LOG=stderr /usr/lib/cloud-init/ds-identify --force [up 2345.15s] ds-identify --force policy loaded: mode=search report=false found=all maybe=all notfound=disabled /etc/cloud/cloud.cfg.d/90_dpkg.cfg set datasource_list: [NoCloud, OVF] DMI_PRODUCT_NAME=VMware Virtual Platform DMI_SYS_VENDOR=VMware, Inc. DMI_PRODUCT_SERIAL=VMware-56 4d 5c 48 27 3b 66 c7-18 31 7d 99 e7 30 40 7e DMI_PRODUCT_UUID=485c4d56-3b27-c766-1831-7d99e730407e PID_1_PRODUCT_NAME=unavailable DMI_CHASSIS_ASSET_TAG=No Asset Tag FS_LABELS= ISO9660_DEVS= KERNEL_CMDLINE=BOOT_IMAGE=/boot/vmlinuz-5.11.0-20-generic root=UUID=e6b98230-678e-4963-88a1-673f9e943acd ro find_preseed=/preseed.cfg auto noprompt priority=critical locale=en_US quiet VIRT=vmware UNAME_KERNEL_NAME=Linux UNAME_KERNEL_RELEASE=5.11.0-20-generic UNAME_KERNEL_VERSION=#21+21.10.1-Ubuntu SMP Wed Jun 9 15:08:14 UTC 2021 UNAME_MACHINE=x86_64 UNAME_NODENAME=ubuntu UNAME_OPERATING_SYSTEM=GNU/Linux DSNAME= DSLIST=NoCloud OVF MODE=search ON_FOUND=all ON_MAYBE=all ON_NOTFOUND=disabled pid=54738 ppid=54737 is_container=false Checking for datasource 'NoCloud' via 'dscheck_NoCloud' check for 'NoCloud' returned not-found[1] Checking for datasource 'OVF' via 'dscheck_OVF' DEBUG: dscheck_OVF: Check seed DEBUG: dscheck_OVF: DI_VIRT DEBUG: dscheck_OVF: is_azure_chassis DEBUG: dscheck_OVF: ovf_vmware_transport_guestinfo Running on vmware but rpctool query returned 1: No value found DEBUG: dscheck_OVF: has_ovf_cdrom DEBUG: dscheck_OVF: ovf_vmware_guest_customization DEBUG: ovf_vmware_guest_customization: start check DEBUG: scan plugin check for 'OVF' returned not-found[1] found= maybe= No ds found [mode=search, notfound=disabled]. Disabled cloud-init [1] [up 2345.23s] returning 1 With the fix (from PPA https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4673) in place it finds the plugin as expected. We want to also force vmware customization itself for this test which isn't the default. $ echo "disable_vmware_customization: false" | sudo tee -a /etc/cloud/cloud.cfg.d/99_test.cfg And then the result is in /etc/cloud-init/cloud.cfg We will see the check say: ... Checking for datasource 'OVF' via 'dscheck_OVF' Running on vmware but rpctool query returned 1: No value found /etc/cloud/cloud.cfg.d/99_test.cfg set disable_vmware_customization to false check for 'OVF' returned found found=OVF maybe= Found single datasource: OVF [up 3357.93s] returning 0 And the result is: $ cat /run/cloud-init/cloud.cfg datasource_list: [ OVF, None ] In comparison the bad case has: ... Checking for datasource 'OVF' via 'dscheck_OVF' Running on vmware but rpctool query returned 1: No value found check for 'OVF' returned not-found[1] found= maybe= No ds found [mode=search, notfound=disabled]. Disabled cloud-init [1] [up 3554.80s] returning 1 And the result is: $ cat /run/cloud-init/cloud.cfg di_report: datasource_list: [ ] # reporting not found result. notfound=disabled. That is enough to construct a testcase for the SRU template ... ** Description changed: [Impact] - * The package correctly fixed a non multiarch path, but we missed - that some depending SW might have mad assumptions on the old paths. - One such SW is cloud-init which in certain cases now fails to detect - and configure vmware correctly. + * The package correctly fixed a non multiarch path, but we missed + that some depending SW might have mad assumptions on the old paths. + One such SW is cloud-init which in certain cases now fails to detect + and configure vmware correctly. - * In the long run (next Debian and 22.04) we will keep only the new - paths. But for 21.10 time is too short and even more so for the SRUs - that we regularly do back to at least the last LTS. - There we want to mitigate the impact by adding a compat link on the - old path. + * In the long run (next Debian and 22.04) we will keep only the new + paths. But for 21.10 time is too short and even more so for the SRUs + that we regularly do back to at least the last LTS. + There we want to mitigate the impact by adding a compat link on the + old path. [Test Plan] - * TBD discussion ongoing + * We need to configure cloud-init to check for VMware IVMF data and we + will see that without the fix it is failing to be detected. + + * Set up Ubuntu in VMWare if you do not ahve any ESXi then VMWare + Workstation player 16 for Ubuntu as trial from + https://www.vmware.com/products/workstation-player/workstation-player- + evaluation.html is enough. + + # Reduce the ouput a bit for readability and make it not skip vmware + $ echo "datasource_list: [NoCloud, OVF]" < sudo tee /etc/cloud/cloud.cfg.d/99_test.cfg + $ echo "disable_vmware_customization: false" | sudo tee -a /etc/cloud/cloud.cfg.d/99_test.cfg + # Run ds-dentify with debug on + $ sudo DEBUG_LEVEL=5 DI_LOG=stderr /usr/lib/cloud-init/ds-identify --force + # Check the result + $ cat /run/cloud-init/cloud.cfg + + + Bad case example: + ... + Checking for datasource 'OVF' via 'dscheck_OVF' + Running on vmware but rpctool query returned 1: No value found + check for 'OVF' returned not-found[1] + found= maybe= + No ds found [mode=search, notfound=disabled]. Disabled cloud-init [1] + [up 3554.80s] returning 1 + + And the result is: + $ cat /run/cloud-init/cloud.cfg + di_report: + datasource_list: [ ] + # reporting not found result. notfound=disabled. + + + Good case example: + ... + Checking for datasource 'OVF' via 'dscheck_OVF' + Running on vmware but rpctool query returned 1: No value found + /etc/cloud/cloud.cfg.d/99_test.cfg set disable_vmware_customization to false + check for 'OVF' returned found + found=OVF maybe= + Found single datasource: OVF + [up 3357.93s] returning 0 + + And the result is: + $ cat /run/cloud-init/cloud.cfg + datasource_list: [ OVF, None ] + + Note: VMware who spotted this will do a verification as well on this + case. [Where problems could occur] - * Since we do not remove, but add a link (that exactly matches the - formerly used path) I'm not too concerned. The issue I can think of - would be e.g. security policies that prevent .so files to load through - symlinks or anything like that. But in that case still the upload - would not further degrade things, it would just not fix it. - Test wise this is all about guest customizations and VMware plugin and - VMware as usual will do checks for that when this is in verification. + * Since we do not remove, but add a link (that exactly matches the + formerly used path) I'm not too concerned. The issue I can think of + would be e.g. security policies that prevent .so files to load through + symlinks or anything like that. But in that case still the upload + would not further degrade things, it would just not fix it. + Test wise this is all about guest customizations and VMware plugin and + VMware as usual will do checks for that when this is in verification. [Other Info] - - * Down the road we still want to drop that path, it is only added now to - temporarily mitigate such issues. Therefore we do NOT want to have that - in 22.04 for a long time, and will most likely drop it there soon to - spot further issues with it. - * For the same reason I'm also not uploading it to Debian via - https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/merge_requests/11 + * Down the road we still want to drop that path, it is only added now to + temporarily mitigate such issues. Therefore we do NOT want to have that + in 22.04 for a long time, and will most likely drop it there soon to + spot further issues with it. + * For the same reason I'm also not uploading it to Debian via + https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/merge_requests/11 ------ Problem: the path of plugin libdeployPkgPlugin.so of open-vm-tools is changed and guest customization will fail for ubuntu 21.10 beta image Description: Ubuntu 21.10 have new open-vm-tools 11.3.0. with this new open-vm-tools, the plugin libdeployPkgPlugin.so is put to directory /usr/lib/x86_64-linux-gnu/open-vm-tools/plugins/vmsvc/. In previous open-vm-tools version (such as 11.2.5), the the plugin libdeployPkgPlugin.so is put to directory /usr/lib/open-vm- tools/plugins/vmsvc/ The path change of plugin libdeployPkgPlugin.so will cause the guest customization failure. -- 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
