I have an Ubuntu 18.04 VM where I added a manual cloud and I am trying to have this machine bootstrap itself as the controller. Everything works fine until Juju get’s to the Running machine configuration script... line where it hangs indefinitely without any extra info even when running juju with the --debug flag.
Is there any log I can view to see what’s going wrong? Is it not possible to have a machine with Juju installed on it bootstrap itself ( without LXD ).
While I have heard of people trying this before, it is certainly not the intent of the manual provider to be able to bootstrap localhost as a manual provider.
If it does work, it is by accident, not by design. There are no tests around this behaviour, and almost by definition, anything that isn’t tested is broken.
So I gave up on bootstrapping the localhost and just add my other vagrant machines using the manual provider and all of them failed with the same problem. They would just hang once it got to “Running configuration script”. I don’t have it right now, I found in the logs the exact command that was hanging indefinitely. It was the one that did something like sudo bash -c 'bash -c 'echo aldfjalsflkjkdjdfjsd==' | base64 -d'.
I can’t figure out what the issue is. I think it might have something to do with the fact that these ubuntu machines don’t start with the ubuntu user and it’s shell isn’t setup or something.
I’m kind of shocked at the fact that I can’t get a 100% clean Ubuntu 18.04 or 20.04 machine to add to a Juju controller using SSH. I’m not sure if there is something weird about my dev environment, but the connectivity is fine and everything and it’s a standardized Ubuntu image I’m trying to add so I don’t know what’s wrong. Does anybody understand what the above trace log is trying to do and why it might just hang indefinitely?
It’s killing my development environment because I have to deploy inside of VMS, but I have to be able to access the Juju machines from my host, which means I can’t use LXD for the Juju machines.