My laptop (Ubuntu 18.04.3 LTS) frequently doesn't get ipv6 routing information until I restart radvd on the linux firewaall. Then everything works fine. Any ideas as to how I can get this to work consistantly without manual intervention?
Juju deploys vms to vsphere with version 10 hardware definition. The boot sequence seems to die configuring the video drivers for the console.
My juju controllers appear to be defaulting to a 10GB root disk. I am running out of disk space on the controller. I have 6.7GB in /var/lib/juju/db. Is there a way to reduce the disk usage on this? If not, can I make the root disk larger? What are my options?
I have already cleared out kernel updates.
I installed 16.04.1 on an old HP DL180 from a usb stick. The installation went correctly, but would not boot. I booted from the usb stick in rescue mode and ran grub-install and update-grub and installed a newer kernel. I even asked the live rescue usb to reinstall the grub boot loader. No errors reported anywhere. When I reboot without the usb stick in, it fails to find grub and just gives a blank screen. When booting from the usb stick as boot from first disk it still goes blank and can't find grub.
I reinstalled from 14.04.5 on a usb stick with all the same parameters and it works fine. Then I did an upgrade to 16.04.1 and it works fine also.
When I try to add a subnet on MAAS 2.0 I have the following configuration:
- VLAN masstest/untagged space masstest
- CIDR 10.20.0.3/16 name testadmin
- Gateway IP 10.20.0.2 DNS 10.20.0.3
When I submit it I get "Extra data: line 1 column 6 (char 5)". What is this trying to tell me?
With a machine newly upgraded to 16.04, I run "lxd init" and it returns with "LXD init cannot be used at this time". What causes this error message? And what do I have to fix so that I can run "lxd init"?
I removed lxc1, uninstalled lxd and reinstalled it, all without success.
I finally uninstalled lxd with a "purge" option and removed the /var/lib/lxd and /var/log/lxd directories, before reinstalling lxd and lxd-client. Now I can run "lxd init", but it didn't create the lxdbr0 bridge.
I have openstack-dashboard installed from openstack-base in a MAAS environment and it seems to be working for almost everything. I can view and change networks/routers/ports and start an instance. I have an instance with a floating IP that I can ping and telnet to the ssh port. ssh ubuntu@floatingip connects and then times out.
Trying to access the console from the dashboard returns: console is currently unavailable. Please try again later.
When I do "juju ssh x" to the nova-compute node where my instance is running, a virst list returns:
Id Name State
----------------------------------------------------
5 instance-00000002 running
but virsh console 5 returns:
Connected to domain instance-00000002
Escape character is ^]
error: internal error: character device <null> is not using a PTY
I have verified that nova-authconsole is up and running.
When I look at /var/lib/instances/{instance}/console.log it shows a full console log and everything from the boot up looks correct. nova-cloud-controller has console-access-protocl set to novnc. console-proxy-ip is set to local.
I suspect that all three methods of trying to access the instance are caused by a single failure, but don't know where else to look for it.
Any ideas of how to track this one down?
My MAAS server has been running for several months, building OpenStack cloud configurations and tearing them down, but then it starts giving the error message
Unable to connect to: ws://hostname:5240/MAAS/ws
when going to to the node list.
I have tried rebooting the server, reconfiguring maas-region-controller, everything I can think of. I can telnet to the port and something is definitely listening on it.
How do I recover from this? My only successful method in the past has been to wipe the disk and do a total reinstall and reconfigure, starting over. This happens regularly.
I have machines under MAAS with 4 interfaces. I want to configure my ceph nodes to use two networks that are not the pxe boot network. MAAS doesn't "up" all of the interfaces when a machine is deployed. What is the best way to get the interfaces (and associated networks) up before I deploy my ceph services?
Do I do an juju add-machine --constraints ... and then do juju deploy ... ceph --to ...?
If I just tell MAAS to acquire and start the machine I can manually add the "auto ethx" lines to /etc/network/interfaces and then shut them down and release them, but the ceph service is left sitting in an "allocating" state. The machine is up and I can juju ssh ceph/0 into it just fine, but there is no /var/log/juju directory and it just waits forever.
I understand that the next release of MAAS will bring up all interfaces for me, but what do I do in the meantime to work around it?
I have a set of machines in MAAS with 4 nics. How do I get a juju deploy to bring up all nics? My Ceph deploy is failing because the right interfaces have not been brought up.
I am running ubuntu 14.04.1 with juju 1.21.3 and deployed ceph to a machine with Intel Virtualization turned off in the bios.
It failed with hook failed: "mon-relation-changed".
I rebooted the machine and fixed the bios setting and rebooted once again. I then attempted to destroy-unit and destroy-machine.
The machine now says that it is dying, but everything is still running.
How do I force it to die so I can reinitialize the machine and try again?
I have ubuntu 14.04.1 with maas 1.7.1 rc4 and juju 1.20.14. My client machine is commissioned and deployed. I can ssh [email protected] and I can juju ssh 1 successfully. I did "juju deploy --config config.yaml ceph --to 1".
juju status ceph looks like:
juju status ceph
environment: maas
machines:
"1":
agent-state: pending
dns-name: cl1stn2.maas
instance-id: /MAAS/api/1.0/nodes/node-caa78cae-a5d5-11e4-b918-180373b04ac9/
series: trusty
hardware: arch=amd64 cpu-cores=16 mem=24576M tags=auitsdisk
services:
ceph:
charm: cs:trusty/ceph-31
exposed: false
relations:
mon:
- ceph
units:
ceph/0:
agent-state: pending
machine: "1"
public-address: cl1stn2.maas
networks:
maas-em1:
provider-id: maas-em1
cidr: 10.20.0.0/24
I don't see any attempt to contact cl1stn2.maas and the status stays in pending for ever. I can ssh to cl1stn2.maas and juju ssh 1 successfully. I don't see anything in the all-machines.log.
Where do I look to find out what it is waiting for?
I have 6 nodes that have all been commissioned. I can ssh to 2 of them with ubuntu@ip_address. The other 4 fail to ssh with
Permission denied (publickey)
Juju deploy fail with
Failed to query node's BMC — Node could not be queried node-3c9e137a-744c-11e4-a75c-180373b04ac9 (esxi10.local) connection timeout.
I have added ntp runs during startup and via cron via commissioning scripts. I have even tried adding a second account, complete with password and public keys, but I can't log into these either.
Why would some machines commission correctly and others not? Any ideas?
I started running openstack-install with a maas server. It told me that none of my servers had wake on lan or ipmi configured and left me hanging. I broke out of it and now can't get it to openstck-install -u (uninstall) correctly. It says that there is a partial install that needs to be uninstalled. I have moved the .juju directory, removed the .cloud-install directory, removed the .maasclidb. I have killed a twisted process. Openstack-intall still claims that I have a previous installation. How to I finish cleaning up the old one so I can proceed?
I have a maas server and 6 mass client machines (2 Dell compute servers and 4 HP storage servers). All 6 clients are declared, commissioned, started, and stopped. None of them seems to want to wake up on lan. (I have to run down to the machine room and push power buttons to wake them up.) After the maas stop command, they are left up and running, but are in the "Ready" state.
juju bootstrap --show-log produces:
2014-10-31 00:57:50 INFO juju.cmd supercommand.go:37 running juju [1.20.11-trusty-amd64 gc]
2014-10-31 00:57:55 INFO juju.environs.bootstrap bootstrap.go:48 bootstrapping environment "maas"
2014-10-31 00:57:55 INFO juju.environs.tools tools.go:187 filtering tools by released version
2014-10-31 00:57:55 INFO juju.environs.tools tools.go:87 reading tools with major.minor version 1.20
2014-10-31 00:57:55 INFO juju.environs.tools tools.go:98 filtering tools by series: trusty
2014-10-31 00:57:56 INFO juju.utils http.go:59 hostname SSL verification enabled
2014-10-31 00:58:01 INFO juju.utils http.go:59 hostname SSL verification enabled
2014-10-31 00:58:07 INFO juju.utils http.go:59 hostname SSL verification enabled
2014-10-31 00:58:12 INFO juju.utils http.go:59 hostname SSL verification enabled
2014-10-31 00:58:19 INFO juju.environs.bootstrap bootstrap.go:60 newest version: 1.20.11
2014-10-31 00:58:19 INFO juju.environs.bootstrap bootstrap.go:88 picked bootstrap tools
version: 1.20.11
Launching instance
2014-10-31 00:58:21 WARNING juju.provider.maas environ.go:434 picked arbitrary tools &{1.20.11-trusty-amd64 https://streams.canonical.com/juju/tools/releases/juju-1.20.11-trusty-amd64.tgz bf40f7f107aa57023e7a3941aadb1f87ca43096d6c6211ae2838bec99caf8886 8112488}
- /MAAS/api/1.0/nodes/node-36b1f146-5964-11e4-b15a-a4badbed0f5c/
Waiting for address
Attempting to connect to esxi05.maas:22
Attempting to connect to esxi05.maas:22
Attempting to connect to 10.20.0.10:22
2014-10-31 01:28:21 ERROR juju.provider.common bootstrap.go:122 bootstrap failed: waited for 30m0s without being able to connect: /var/lib/juju/nonce.txt does not exist
Stopping instance...
Bootstrap failed, destroying environment
2014-10-31 01:28:21 INFO juju.provider.common destroy.go:15 destroying environment "maas"
2014-10-31 01:28:21 ERROR juju.cmd supercommand.go:323 waited for 30m0s without being able to connect: /var/lib/juju/nonce.txt does not exist
Do the clients need to be Pxe booted when juju tries to bootstrap?
Can I continue to do a juju deploy without having juju "reinstall the os on the clients"?