I need help with juju bootstrap in maas environment. I have installed maas on maas controller server, commissioned one blade and tried to bootstrap the machine with juju.

System installs on the new blade, juju logs in with ubuntu user via ssh and gets stuck at this point of installation process of juju services:

Logging to /var/log/cloud-init-output.log on remote host

Running apt-get update

Running apt-get upgrade

Installing package: git

Installing package: curl

Installing package: cpu-checker

Installing package: bridge-utils

Installing package: rsyslog-gnutls

Fetching tools: curl -sSfw 'tools from %{url_effective} downloaded: HTTP %{http_code}; time %{time_total}s; size %{size_download} bytes; speed %{speed_download} bytes/s ' --retry 10 -o $bin/tools.tar.gz 'https://streams.canonical.com/juju/tools/releases/juju-1.20.11-trusty-amd64.tgz'

Any help would be appreciated, because I cannot move forward from this point except to terminate bootstrapping process.



Problem resolved. If you ssh to a server and your keyboard layout is not the same as the language settings on the server juju fails to bootstrap the system. I have changed my layout to en_US and bootstrapping worked fine. It's the similar problem when you install postgresql where it fails to install if you don't have the same keyboard layout language as the system language on the server.


I have exactly the same problem, juju boostrapping is stuck. I tried to change the locale setting, but nothing helped.

here is what I did: check your settings


temporary fix

export LANGUAGE=en_US.UTF-8 
export LANG=en_US.UTF-8 
export LANGUAGE=en_US.UTF-8 
export LC_ALL=en_US.UTF-8 
locale-gen en_US.UTF-8 

make it permanent

nano /etc/environment


  • did you change this on the controller image itself? or the locale of the machine where you execute the bootstrap command? – Erik Nov 1 '18 at 14:57

I also had this problem. The root of the problem for me was that I had no internet access and needed to to do a couple of things. IIRC, this particular this was being caused by the time of the server and target machine being off by too large an amount of time. It was not actually stuck, but the time out was huge, maybe 30 minutes. I set my server as an ntp server, then I edited my /etc/maas/preseeds/preseed-master

    d-I      clock-setup/ntp-server    string  ntp.ubuntu.com

Put your server's IP or name in for ntp.ubuntu.com. Also, when you install juju, you need to copy the charms locally. I made a ~/,juju directory for both the environment and charms, so the process, up to deploying juju-gui, looked like this:

mkdir ~./.juju/sync-tools

juju sync-tools –e maas –destination=”~/.juju/sync-tools”

juju bootstrap –e maas –-upload-tools=true –-metadata-source=”.juju/sync-tools” -–to jujuBS.local

mkdir –p ~/.juju/charms/trusty

juju charm get juju-gui .juju/charms/trusty

juju deploy –repository=”~/.juju/charms” local:juju-gui

Hope this helps!


For anyone having this issue after adding machines to the local provider: I had this issue when add-machine tried to add a machine with a Juju version different from the state server.

This was caused by not running apt-get update before installing the Juju client.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.