ERROR selecting releases: charm or bundle not found for channel "stable", base "amd64/ubuntu/22.04/stable"

[Nobuto Murata]

$ juju version
3.4.0-genericlinux-amd64

How to reproduce:
1. bootstrap Juju with MAAS provider
    $ juju bootstrap maas maas-controller
2. try to deploy the juju-dashboard charm to an existing machine
    $ juju deploy -m controller juju-dashboard --to 0

$ juju deploy -m controller juju-dashboard --to 0
ERROR selecting releases: charm or bundle not found for channel "stable", base "amd64/ubuntu/22.04/stable"
available releases are:
  channel "latest/stable": available bases are: ubuntu@22.04, ubuntu@20.04
  channel "latest/candidate": available bases are: ubuntu@22.04, ubuntu@20.04
  channel "latest/beta": available bases are: ubuntu@22.04, ubuntu@20.04
  channel "latest/edge": available bases are: ubuntu@22.04, ubuntu@20.04
ERROR failed to deploy charm "juju-dashboard"

$ juju status -m controller
Model Controller Cloud/Region Version SLA Timestamp
controller maas-controller maas/default 3.4.0 unsupported 05:23:31Z

App Version Status Scale Charm Channel Rev Exposed Message
controller active 1 juju-controller 3.4/stable 79 no

Unit Workload Agent Machine Public address Ports Message
controller/0* active idle 0 192.168.151.101

Machine State Address Inst id Base AZ Message
0 started 192.168.151.101 normal-tiger ubuntu@22.04 default Deployed

[Nobuto Murata (nobuto)]

Just to give another data point, it doesn't fail with Juju 3.1.

[Ian Booth (wallyworld)]

If this is a regression from 3.1, then that's a problem.

We'll need to see logging with the logging-config #charmhub=TRACE

I'll mark as critical pending further investigation.

[Nobuto Murata (nobuto)]

I've attached the whole TRACE log in both cases above. Let me know if you need further logs.

[Jack Shaw (jack-shaw)]

I have been able to replicate this in both 3.3 and 3.4

There is a fairly simple work around, you can just deploy with:

  juju deploy juju-dashboard --to 0 --base ubuntu@22.04

[John A Meinel (jameinel)]

Not critical, as it has been this way for all of 3.3+, but a high importance bug that should be fixed in 3.3 and in 3.4.
There is a workaround (explicitly specify a base).
The particular issue is that when using '--to' our discovery of what base the target is running ends up including extra information that is not supported by charmhub when we do the lookup for a charm.

[Rob Gibbon (robgibbon)]

Just to remark that I also hit this when deploying Charmed MicroK8s to physical system inventory managed by MAAS. The workaround "works", but its yet another papercut in our UX.

[Jack Shaw (jack-shaw)]

A fix has been committed, expect to see it available in the next 3.3 release

https://github.com/juju/juju/pull/16984