[Bug 1524339] [NEW] virsh failure to start lxc container - internal error: Unable to find 'cpuacct' cgroups controller mount
Public bug reported: Seeing libvirt error while trying to deploy instances in OpenStack deployment: "error: internal error: Unable to find 'cpuacct' cgroups controller mount". This is recreatable for kilo and liberty. The cloud version for kilo is root@lambert:~# dpkg -l|grep virt ii libvirt-bin 1.2.12-0ubuntu14.2~cloud0 amd64programs f or the libvirt library ii libvirt01.2.12-0ubuntu14.2~cloud0 amd64library fo r interfacing with different virtualization systems And I was also able to recreate with liberty version: root@lambert:/etc/apt/sources.list.d# apt-cache policy libvirt-bin libvirt-bin: Installed: 1.2.16-2ubuntu11~cloud0 Candidate: 1.2.16-2ubuntu11~cloud0 Version table: *** 1.2.16-2ubuntu11~cloud0 0 500 http://ubuntu-cloud.archive.canonical.com/ubuntu/ trusty-updates/liberty/main amd64 Packages 100 /var/lib/dpkg/status 1.2.2-0ubuntu13.1.14 0 500 http://archive.ubuntu.com//ubuntu/ trusty-updates/main amd64 Packages 1.2.2-0ubuntu13.1.7 0 500 http://archive.ubuntu.com//ubuntu/ trusty-security/main amd64 Packages 1.2.2-0ubuntu13 0 500 http://archive.ubuntu.com//ubuntu/ trusty/main amd64 Packages When I tried on a system with 1.2.2-0ubuntu13.1.7, there was no issue starting the container. If this is an issue with the version in the cloud archives, when was it fixed and when does the fix makes it to the kilo and liberty cloud archives? Below is the error on the nova-compute node with actual instance xml and I also recreated with a basic container: root@lambert:~# virsh -c lxc:/// dumpxml instance-0001 instance-0001 9d5ecebb-f387-4eb7-b337-c1a47589094b http://openstack.org/xmlns/libvirt/nova/1.0;> guestOS-test-lxc-precise_0 2015-12-09 11:12:13 2048 20 0 0 1 admin admin 2097152 1 1024 exe /sbin/init console=tty0 console=ttyS0 console=ttyAMA0 destroy restart destroy /usr/lib/libvirt/libvirt_lxc [583/1825] root@lambert:~# virsh -c lxc:/// start instance-0001 error: Failed to start domain instance-0001 error: internal error: Unable to find 'cpuacct' cgroups controller mount root@lambert:~# virsh -c lxc:/// dumpxml myinstance myinstance 704269a9-d9ae-49eb-ae5e-1222fd703872 102400 102400 1 exe /bin/sh destroy restart destroy /usr/lib/libvirt/libvirt_lxc root@lambert:~# virsh -c lxc:/// start myinstance error: Failed to start domain myinstance error: internal error: Unable to find 'cpuacct' cgroups controller mount ** Affects: cloud-archive Importance: Undecided Status: New ** Affects: libvirt (Ubuntu) Importance: Undecided Status: New ** Tags: oil ** Also affects: cloud-archive Importance: Undecided Status: New ** Summary changed: - Failure to start lxc container - internal error: Unable to find 'cpuacct' cgroups controller mount + virsh failure to start lxc container - internal error: Unable to find 'cpuacct' cgroups controller mount -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in Ubuntu. https://bugs.launchpad.net/bugs/1524339 Title: virsh failure to start lxc container - internal error: Unable to find 'cpuacct' cgroups controller mount To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1524339/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1429739] Re: neutron-server does not start: OperationalError: (OperationalError) no such table: ml2_vlan_allocations
I hit similar issue in trusty. The following error is repeated multiple
times in server.log:
2015-11-11 20:20:40.238 9354 TRACE neutron File
"/usr/lib/python2.7/dist-packages/sqlalchemy/engine/default.py", line 436, in
do_execute
2015-11-11 20:20:40.238 9354 TRACE neutron cursor.execute(statement,
parameters)
2015-11-11 20:20:40.238 9354 TRACE neutron OperationalError: (OperationalError)
no such table: ml2_vlan_allocations u'SELECT
ml2_vlan_allocations.physical_network AS ml2_vlan_allocations
_physical_network, ml2_vlan_allocations.vlan_id AS
ml2_vlan_allocations_vlan_id, ml2_vlan_allocations.allocated AS
ml2_vlan_allocations_allocated \nFROM ml2_vlan_allocations' ()
2015-11-11 20:20:40.238 9354 TRACE neutron
2015-11-11 20:20:41.166 9371 ERROR neutron.service [-] Unrecoverable error:
please check log for details.
2015-11-11 20:20:41.166 9371 TRACE neutron.service Traceback (most recent call
last):
2015-11-11 20:20:41.166 9371 TRACE neutron.service File
"/usr/lib/python2.7/dist-packages/neutron/service.py", line 102, in serve_wsgi
2015-11-11 20:20:41.166 9371 TRACE neutron.service service.start()
2015-11-11 20:20:41.166 9371 TRACE neutron.service File
"/usr/lib/python2.7/dist-packages/neutron/service.py", line 73, in start
2015-11-11 20:20:41.166 9371 TRACE neutron.service self.wsgi_app =
_run_wsgi(self.app_name)
2015-11-11 20:20:41.166 9371 TRACE neutron.service File
"/usr/lib/python2.7/dist-packages/neutron/service.py", line 168, in _run_wsgi
2015-11-11 20:20:41.166 9371 TRACE neutron.service app =
config.load_paste_app(app_name)
2015-11-11 20:20:41.166 9371 TRACE neutron.service File
"/usr/lib/python2.7/dist-packages/neutron/common/config.py", line 183, in
load_paste_app
2015-11-11 20:20:41.166 9371 TRACE neutron.service app =
deploy.loadapp("config:%s" % config_path, name=app_name)
2015-11-11 20:20:41.166 9371 TRACE neutron.service File
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 247, in
loadapp
2015-11-11 20:20:41.166 9371 TRACE neutron.service return loadobj(APP, uri,
name=name, **kw)
2015-11-11 20:20:41.166 9371 TRACE neutron.service File
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 272, in
loadobj
2015-11-11 20:20:41.166 9371 TRACE neutron.service return context.create()
2015-11-11 20:20:41.166 9371 TRACE neutron.service File
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 710, in create
2015-11-11 20:20:41.166 9371 TRACE neutron.service return
self.object_type.invoke(self)
2015-11-11 20:20:41.166 9371 TRACE neutron.service File
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 144, in invoke
2015-11-11 20:20:41.166 9371 TRACE neutron.service **context.local_conf)
2015-11-11 20:20:41.166 9371 TRACE neutron.service File
"/usr/lib/python2.7/dist-packages/paste/deploy/util.py", line 55, in fix_call
2015-11-11 20:20:41.166 9371 TRACE neutron.service val = callable(*args,
**kw)
2015-11-11 20:20:41.166 9371 TRACE neutron.service File
"/usr/lib/python2.7/dist-packages/paste/urlmap.py", line 28, in urlmap_factory
2015-11-11 20:20:41.166 9371 TRACE neutron.service app =
loader.get_app(app_name, global_conf=global_conf)
2015-11-11 20:20:41.166 9371 TRACE neutron.service File
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 350, in
get_app
2015-11-11 20:20:41.166 9371 TRACE neutron.service name=name,
global_conf=global_conf).create()
2015-11-11 20:20:41.166 9371 TRACE neutron.service File
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 710, in create
2015-11-11 20:20:41.166 9371 TRACE neutron.service return
self.object_type.invoke(self)
2015-11-11 20:20:41.166 9371 TRACE neutron.service File
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 144, in invoke
2015-11-11 20:20:41.166 9371 TRACE neutron.service **context.local_conf)
2015-11-11 20:20:41.166 9371 TRACE neutron.service File
"/usr/lib/python2.7/dist-packages/paste/deploy/util.py", line 55, in fix_call
2015-11-11 20:20:41.166 9371 TRACE neutron.service val = callable(*args,
**kw)
2015-11-11 20:20:41.166 9371 TRACE neutron.service File
"/usr/lib/python2.7/dist-packages/neutron/auth.py", line 71, in pipeline_factory
2015-11-11 20:20:41.166 9371 TRACE neutron.service app =
loader.get_app(pipeline[-1])
2015-11-11 20:20:41.166 9371 TRACE neutron.service File
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 350, in
get_app
2015-11-11 20:20:41.166 9371 TRACE neutron.service name=name,
global_conf=global_conf).create()
2015-11-11 20:20:41.166 9371 TRACE neutron.service File
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 710, in create
2015-11-11 20:20:41.166 9371 TRACE neutron.service return
self.object_type.invoke(self)
2015-11-11 20:20:41.166 9371 TRACE neutron.service File
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 146,
[Bug 1429739] Re: neutron-server does not start: OperationalError: (OperationalError) no such table: ml2_vlan_allocations
Attaching /var/log/neutron/server.log ** Attachment added: "server.log.gz" https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1429739/+attachment/4517291/+files/server.log.gz ** Tags added: oil -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to neutron in Ubuntu. https://bugs.launchpad.net/bugs/1429739 Title: neutron-server does not start: OperationalError: (OperationalError) no such table: ml2_vlan_allocations To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1429739/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1429739] Re: neutron-server does not start: OperationalError: (OperationalError) no such table: ml2_vlan_allocations
I was able to recreate. The errors are same on the retry. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to neutron in Ubuntu. https://bugs.launchpad.net/bugs/1429739 Title: neutron-server does not start: OperationalError: (OperationalError) no such table: ml2_vlan_allocations To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1429739/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1463046] Re: installation of multipath-tools-boot can break boot
** Tags added: oil -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to multipath-tools in Ubuntu. https://bugs.launchpad.net/bugs/1463046 Title: installation of multipath-tools-boot can break boot To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1463046/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1370249] Re: 'ascii' codec can't decode byte 0xc3 in position 19027: ordinal not in range(128) (curtin can't handle non-ascii characters in dpkg --list output)
** Tags removed: verification-needed ** Tags added: verification-done -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to curtin in Ubuntu. https://bugs.launchpad.net/bugs/1370249 Title: 'ascii' codec can't decode byte 0xc3 in position 19027: ordinal not in range(128) (curtin can't handle non-ascii characters in dpkg --list output) To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1370249/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1370249] Re: 'ascii' codec can't decode byte 0xc3 in position 19027: ordinal not in range(128) (curtin can't handle non-ascii characters in dpkg --list output)
I verified this for trusty deployment with maas 1.7.0+bzr3299-0ubuntu3~trusty1 and curtin version was 0.1.0~bzr195-0ubuntu1~14.04.1~ppa0. The steps to test this was to edit the root-tgz after uncompressing and extracting it, doing a chroot. I then did a sudo apt-get install deja- dup-backend-gvfs which also installed deja-dup and fonts-dejavu-core. The non-ascii characters were in description for deja-dup-backend-gvfs: Remote server support for Déjà Dup. After exiting, I then recreated the compressed tgz image from the modified files and copied the file to cached filename in /var/lib/maas/boot-resources/cache, and to root-tgz file in /var/lib/maas/boot- resources/current/ubuntu/amd64/generic/trusty/daily. Finally, I restarted tgt. I then deployed trusty through maas which worked. The 2nd test was to do a juju bootstrap which also passed. To make sure that I was dealing with the right image, I verified that the deja-up packages were installed on the deployed node. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to curtin in Ubuntu. https://bugs.launchpad.net/bugs/1370249 Title: 'ascii' codec can't decode byte 0xc3 in position 19027: ordinal not in range(128) (curtin can't handle non-ascii characters in dpkg --list output) To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1370249/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1313550] Re: ping does not work as a normal user on trusty tarball cloud images.
This was the test case: 1) Update trusty daily root-tgz image with a copy of dcap and cap properties. 2) Sync image to cache 3) Deploy a node with trusty 4) Access deployed node 5) Ensure that cap properties for the new file are preserved on deployed system. This test passed. Here are test details: == 1) Update image root@ubuntumaas:/var/lib/maas/boot-resources/cache/root# ls -l usr/bin/dpkgcap -rwxr-xr-x 1 root root 261840 Dec 17 09:33 usr/bin/dpkgcap root@ubuntumaas:/var/lib/maas/boot-resources/cache/root# getcap usr/bin/dpkgcap usr/bin/dpkgcap = cap_net_raw+p root@ubuntumaas:/var/lib/maas/boot-resources/cache/root# tar --xattrs '--xattrs-include=*' -czf root.tar.gz * tar: root.tar.gz: file changed as we read it 2) Sync image root@ubuntumaas:/var/lib/maas/boot-resources/cache/root# ls -l total 550812 drwxr-xr-x 2 root root 4096 Dec 17 02:54 bin drwxr-xr-x 3 root root 4096 Dec 8 14:34 boot drwxr-xr-x 6 root root 4096 Dec 8 14:34 dev drwxr-xr-x 96 root root 4096 Dec 17 02:56 etc drwxr-xr-x 2 root root 4096 Apr 10 2014 home lrwxrwxrwx 1 root root33 Dec 8 14:33 initrd.img - boot/initrd.img-3.13.0-40-generic drwxr-xr-x 22 root root 4096 Dec 8 14:31 lib drwxr-xr-x 2 root root 4096 Dec 4 18:40 lib64 drwx-- 2 root root 4096 Dec 4 18:43 lost+found drwxr-xr-x 2 root root 4096 Dec 4 18:40 media drwxr-xr-x 2 root root 4096 Apr 10 2014 mnt drwxr-xr-x 2 root root 4096 Dec 4 18:40 opt drwxr-xr-x 2 root root 4096 Apr 10 2014 proc drwx-- 2 root root 4096 Dec 17 02:05 root -rw-r--r-- 1 root root 563942052 Dec 17 09:40 root.tar.gz drwxr-xr-x 4 root root 4096 Dec 8 14:33 run drwxr-xr-x 2 root root 4096 Dec 17 02:54 sbin drwxr-xr-x 2 root root 4096 Dec 4 18:40 srv drwxr-xr-x 2 root root 4096 Mar 12 2014 sys drwxrwxrwt 4 root root 4096 Dec 17 02:55 tmp drwxr-xr-x 10 root root 4096 Dec 4 18:40 usr drwxr-xr-x 12 root root 4096 Dec 4 18:43 var lrwxrwxrwx 1 root root30 Dec 8 14:33 vmlinuz - boot/vmlinuz-3.13.0-40-generic root@ubuntumaas:/var/lib/maas/boot-resources/cache/root# ls -l ../root-tgz-3d15bdc99ae5cfe7e0be2e06e084636dc6fd809ec09ca54732ec83c9224376a2 -rw-r--r-- 1 root root 424884409 Dec 17 03:28 ../root-tgz-3d15bdc99ae5cfe7e0be2e06e084636dc6fd809ec09ca54732ec83c9224376a2 root@ubuntumaas:/var/lib/maas/boot-resources/cache/root# cp root.tar.gz ../root-tgz-3d15bdc99ae5cfe7e0be2e06e084636dc6fd809ec09ca54732ec83c9224376a2 root@ubuntumaas:/var/lib/maas/boot-resources/cache/root# ls -l ../root-tgz-3d15bdc99ae5cfe7e0be2e06e084636dc6fd809ec09ca54732ec83c9224376a2 -rw-r--r-- 1 root root 563942052 Dec 17 09:42 ../root-tgz-3d15bdc99ae5cfe7e0be2e06e084636dc6fd809ec09ca54732ec83c9224376a2 root@ubuntumaas:/var/lib/maas/boot-resources/cache/root# service tgt restart tgt stop/waiting tgt start/running, process 16692 root@ubuntumaas:/var/lib/maas/boot-resources/cache/root# cp ../root-tgz-3d15bdc99ae5cfe7e0be2e06e084636dc6fd809ec09ca54732ec83c9224376a2 ../../current/ubuntu/amd64/generic/trusty/daily/root-tgz root@ubuntumaas:/var/lib/maas/boot-resources/cache/root# sync;sync root@ubuntumaas:/var/lib/maas/boot-resources/cache/root# exit logout 3) Deploy node from maas 4) Access deployed node lmic@ubuntumaas:/var/lib/maas/boot-resources/cache/root$ ssh 192.168.224.100 @@@ @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is 5b:1b:de:c3:ff:d6:e5:64:3c:b7:be:19:55:69:b5:7e. Please contact your system administrator. Add correct host key in /home/lmic/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /home/lmic/.ssh/known_hosts:20 remove with: ssh-keygen -f /home/lmic/.ssh/known_hosts -R 192.168.224.100 ECDSA host key for 192.168.224.100 has changed and you have requested strict checking. Host key verification failed. lmic@ubuntumaas:/var/lib/maas/boot-resources/cache/root$ ssh-keygen -f /home/lmic/.ssh/known_hosts -R 192.168.224.100 # Host 192.168.224.100 found: line 20 type ECDSA /home/lmic/.ssh/known_hosts updated. Original contents retained as /home/lmic/.ssh/known_hosts.old lmic@ubuntumaas:/var/lib/maas/boot-resources/cache/root$ ssh 192.168.224.100 The authenticity of host '192.168.224.100 (192.168.224.100)' can't be established. ECDSA key fingerprint is 5b:1b:de:c3:ff:d6:e5:64:3c:b7:be:19:55:69:b5:7e. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.224.100' (ECDSA) to the list of known hosts. Permission denied (publickey).
