** Description changed: [Impact] This bug impacts users which: - - Do not have the '/usr/bin/cloud-id' command in their system, + - Do not have the '/usr/bin/cloud-id' command in their system, - Do have the '/var/lib/cloud/data/result.json' file in their system, and - - Have a non-standart (by cloud-init definitions) content in the '/var/lib/cloud/data/result.json' file. + - Have a non-standard (by cloud-init definitions) content in the '/var/lib/cloud/data/result.json' file. This is an unusual situation, given that the presence of the 'result.json' file with the absence of the 'cloud-id' command is observed on official Trusty images, but from Xenial onwards 'cloud-id' should be there. Even in the case where the command is not there, the file generated by cloud-init will have the required information. Since we are doing the SRU process for Xenial onwards, the solution for those problems is to rely only on cloud-id when trying to determine the cloud type, and assuming not on cloud when the command is not present or if it fails. https://github.com/canonical/ubuntu-advantage-client/commit/f6fbcee792cf42cc67e3ced02815b7d552dee19f [Test Case] To reproduce: With ubuntu-advantage-tools 27.2 installed, in an Ubuntu machine: - - Make sure cloud-id is not there: - $ sudo mv /usr/bin/cloud-id /usr/bin/cloud-id.old - - Make sure to have the result.json file with non-standart (empty, for instance) content: - $ sudo mv /var/lib/cloud/data/result.json /var/lib/cloud/data/result.json.old (if the file exists) - $ sudo touch /var/lib/cloud/data/result.json + - Make sure cloud-id is not there: + $ sudo mv /usr/bin/cloud-id /usr/bin/cloud-id.old + - Make sure to have the result.json file with non-standard (empty, for instance) content: + $ sudo mv /var/lib/cloud/data/result.json /var/lib/cloud/data/result.json.old (if the file exists) + $ sudo touch /var/lib/cloud/data/result.json - Try to attach a token using "ua attach" - Verify that it fails To verify the fix: Repeat the above process using ubuntu-advantage tools 27.3, and verify that the attach operation succeeds. - [Regression Potential] When running on a non-cloud system, this fix brings no impact, as we expect cloud-id to be absent and we are not running on cloud. When running on a specific cloud, this fix brings the scenario where we should detect the cloud and are unable to, due to problems with cloud- init. This is minor though, given that if cloud-init didn't run properly, the instance has more problems than this one. Besides that, considering no-cloud when not in aws/azure/gcp has no impact on UA at all, and those three providers have images with cloud-id working properly. No official Ubuntu image should be affected by this change. - [Discussion] As stated above, this is an unusual situation, which led to an improvement to the cloud detection in UA. - [Original Description] sudo ua status Unexpected error(s) occurred. For more details, see the log: /var/log/ubuntu-advantage.log To file a bug run: ubuntu-bug ubuntu-advantage-tools ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: ubuntu-advantage-tools 27.2.2~18.04.1 ProcVersionSignature: Ubuntu 4.15.0-153.160-generic 4.15.18 Uname: Linux 4.15.0-153-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.24 Architecture: amd64 Date: Mon Aug 16 19:14:53 2021 InstallationDate: Installed on 2019-08-12 (735 days ago) InstallationMedia: SourcePackage: ubuntu-advantage-tools UpgradeStatus: No upgrade log present (probably fresh install)
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1940131 Title: sudo ua attach is not working To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1940131/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
