canonical-ubuntu-qa team mailing list archive
-
canonical-ubuntu-qa team
-
Mailing list archive
-
Message #04101
[Bug 2067072] [NEW] failure: sudo failed with stderr: "sudo: unable to resolve host autopkgtest"
Public bug reported:
This is biting us again?
https://autopkgtest.ubuntu.com/results/autopkgtest-
xenial/xenial/i386/u/ubuntu-advantage-
tools/20240524_123321_36163@/log.gz
Note that:
0. The test log says `git checkout: 699e7f9f ssh-setup/nova: explicitely
set 'fqdn' in cloud-init` which is the very commit that should prevent
this failure from happening. :(
1. This is an i386 test, but the failure happened very early, so maybe
the fact that it's i386 is not relevant. *Unless* we're running some
early command like `dpkg --add-architecture i386` and that happens to be
racy with cloud-init. E.g. I don't see us doing stuff like `cloud-init
status --wait` in setup-testbed.
2. This is a Xenial test. Xenial has an older cloud-init:
cloud-init | 21.1-19-gbad84ad4-0ubuntu1~16.04.2 | xenial-updates |
cloud-init | 24.1.3-0ubuntu1~20.04.1 | focal-updates |
cloud-init | 24.1.3-0ubuntu1~22.04.1 | jammy-updates |
cloud-init | 24.1.3-0ubuntu1~23.10.2 | mantic-updates |
cloud-init | 24.1.3-0ubuntu3 | noble |
cloud-init | 24.1.3-0ubuntu3.2 | noble-proposed |
Does the fqdn setting behave differently there? Does it work at all?
** Affects: auto-package-testing
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Auto Package Testing.
https://bugs.launchpad.net/bugs/2067072
Title:
failure: sudo failed with stderr: "sudo: unable to resolve host
autopkgtest"
Status in Auto Package Testing:
New
Bug description:
This is biting us again?
https://autopkgtest.ubuntu.com/results/autopkgtest-
xenial/xenial/i386/u/ubuntu-advantage-
tools/20240524_123321_36163@/log.gz
Note that:
0. The test log says `git checkout: 699e7f9f ssh-setup/nova:
explicitely set 'fqdn' in cloud-init` which is the very commit that
should prevent this failure from happening. :(
1. This is an i386 test, but the failure happened very early, so maybe
the fact that it's i386 is not relevant. *Unless* we're running some
early command like `dpkg --add-architecture i386` and that happens to
be racy with cloud-init. E.g. I don't see us doing stuff like `cloud-
init status --wait` in setup-testbed.
2. This is a Xenial test. Xenial has an older cloud-init:
cloud-init | 21.1-19-gbad84ad4-0ubuntu1~16.04.2 | xenial-updates |
cloud-init | 24.1.3-0ubuntu1~20.04.1 | focal-updates |
cloud-init | 24.1.3-0ubuntu1~22.04.1 | jammy-updates |
cloud-init | 24.1.3-0ubuntu1~23.10.2 | mantic-updates |
cloud-init | 24.1.3-0ubuntu3 | noble |
cloud-init | 24.1.3-0ubuntu3.2 | noble-proposed |
Does the fqdn setting behave differently there? Does it work at all?
To manage notifications about this bug go to:
https://bugs.launchpad.net/auto-package-testing/+bug/2067072/+subscriptions
Follow ups