A successful MAAS boot-image download proves the controller's route. If the installed machine later cannot fetch packages, inspect the consumer at that stage:

StageConsumer to inspect
Image/provisioning downloadThe responsible controller service
Commissioning or installationThe temporary task environment
Installed OS packagesThe package manager and generated configuration
Later charm, script or application downloadThe client making that request

Use the supported controls of the MAAS version in service. Documented enable_http_proxy covers use of the built-in or specified proxy for provisioning and package access; http_proxy identifies an external service. In peer-proxy mode, deployed machines can use MAAS's built-in proxy, which uses that external service as its parent. For permitted use of a public external parent, choose an HTTP candidate from the HTTP proxy list; keep the node's MAAS-local endpoint unchanged in peer-proxy mode.

A MAAS-local endpoint on the node is therefore not necessarily stale. Follow its parent before replacing it with the external address. Old preseed workarounds from releases that did not pass proxy settings to nodes do not describe every current deployment.

At the failing stage, compare generated package settings, endpoint reachability and authentication identity with the installer environment. They need not share a home directory or variables. On an Ubuntu node using APT, inspect APT's own proxy options. Keep local metadata access separate from public repositories; sending an internal provisioning URL to the external parent can fail while public downloads work.

A controller shell or browser is another consumer, and a configured package manager does not configure every later runtime. After a management change, inspect what the affected existing workload actually received rather than assuming it immediately reloaded the setting.

Erthyglow kevrennek