← Back to team overview

canonical-ubuntu-qa team mailing list archive

[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