[Touch-packages] [Bug 1665160] Re: MachineSuite.TestMachineWorkers timed out waiting for workers zesty because dbus is in interactive mode
Is the unit test messing with the services on the host system? I hope
not.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dbus in Ubuntu.
https://bugs.launchpad.net/bugs/1665160
Title:
MachineSuite.TestMachineWorkers timed out waiting for workers zesty
because dbus is in interactive mode
Status in juju:
Triaged
Status in juju 2.1 series:
Won't Fix
Status in dbus package in Ubuntu:
New
Bug description:
As seen at
http://reports.vapour.ws/releases/issue/5768c750749a563f2d7daa6e
A unit test is exclusively failing on our new zesty machine. the
previous issues is not related to the zesty falures
machine-0: has workers [agent api-address-updater api-caller
api-config-watcher disk-manager log-forwarder log-sender logging-config-updater
machine-action-runner machiner migration-fortress migration-inactive-flag
migration-minion proxy-config-updater reboot-executor ssh-authkeys-updater
state-config-watcher storage-provisioner termination-signal-handler
unconverted-api-workers upgrade-check-flag upgrade-check-gate
upgrade-steps-flag upgrade-steps-gate upgrader]
machine-0: waiting for [unit-agent-deployer]
machine-0: unexpected []
machine-0: report:
{}
machine_test.go:1272:
WaitMatch(c, matcher.Check, coretesting.LongWait,
s.BackingState.StartSync)
engine_test.go:234:
c.Fatalf("timed out waiting for workers")
... Error: timed out waiting for workers
To manage notifications about this bug go to:
https://bugs.launchpad.net/juju/+bug/1665160/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1665160] Re: MachineSuite.TestMachineWorkers timed out waiting for workers zesty because dbus is in interactive mode
** Changed in: juju
Status: Incomplete => Triaged
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dbus in Ubuntu.
https://bugs.launchpad.net/bugs/1665160
Title:
MachineSuite.TestMachineWorkers timed out waiting for workers zesty
because dbus is in interactive mode
Status in juju:
Triaged
Status in juju 2.1 series:
Won't Fix
Status in dbus package in Ubuntu:
New
Bug description:
As seen at
http://reports.vapour.ws/releases/issue/5768c750749a563f2d7daa6e
A unit test is exclusively failing on our new zesty machine. the
previous issues is not related to the zesty falures
machine-0: has workers [agent api-address-updater api-caller
api-config-watcher disk-manager log-forwarder log-sender logging-config-updater
machine-action-runner machiner migration-fortress migration-inactive-flag
migration-minion proxy-config-updater reboot-executor ssh-authkeys-updater
state-config-watcher storage-provisioner termination-signal-handler
unconverted-api-workers upgrade-check-flag upgrade-check-gate
upgrade-steps-flag upgrade-steps-gate upgrader]
machine-0: waiting for [unit-agent-deployer]
machine-0: unexpected []
machine-0: report:
{}
machine_test.go:1272:
WaitMatch(c, matcher.Check, coretesting.LongWait,
s.BackingState.StartSync)
engine_test.go:234:
c.Fatalf("timed out waiting for workers")
... Error: timed out waiting for workers
To manage notifications about this bug go to:
https://bugs.launchpad.net/juju/+bug/1665160/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1665160] Re: MachineSuite.TestMachineWorkers timed out waiting for workers zesty
** Also affects: dbus (Ubuntu)
Importance: Undecided
Status: New
** Summary changed:
- MachineSuite.TestMachineWorkers timed out waiting for workers zesty
+ MachineSuite.TestMachineWorkers timed out waiting for workers zesty because
dbus is in interactive mode
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dbus in Ubuntu.
https://bugs.launchpad.net/bugs/1665160
Title:
MachineSuite.TestMachineWorkers timed out waiting for workers zesty
because dbus is in interactive mode
Status in juju:
Incomplete
Status in juju 2.1 series:
Won't Fix
Status in dbus package in Ubuntu:
New
Bug description:
As seen at
http://reports.vapour.ws/releases/issue/5768c750749a563f2d7daa6e
A unit test is exclusively failing on our new zesty machine. the
previous issues is not related to the zesty falures
machine-0: has workers [agent api-address-updater api-caller
api-config-watcher disk-manager log-forwarder log-sender logging-config-updater
machine-action-runner machiner migration-fortress migration-inactive-flag
migration-minion proxy-config-updater reboot-executor ssh-authkeys-updater
state-config-watcher storage-provisioner termination-signal-handler
unconverted-api-workers upgrade-check-flag upgrade-check-gate
upgrade-steps-flag upgrade-steps-gate upgrader]
machine-0: waiting for [unit-agent-deployer]
machine-0: unexpected []
machine-0: report:
{}
machine_test.go:1272:
WaitMatch(c, matcher.Check, coretesting.LongWait,
s.BackingState.StartSync)
engine_test.go:234:
c.Fatalf("timed out waiting for workers")
... Error: timed out waiting for workers
To manage notifications about this bug go to:
https://bugs.launchpad.net/juju/+bug/1665160/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1635639] Re: Seccomp error with 2.0.5-0ubuntu1~ubuntu16.04.1 on s390x
** Changed in: juju-ci-tools Status: In Progress => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1635639 Title: Seccomp error with 2.0.5-0ubuntu1~ubuntu16.04.1 on s390x Status in juju-ci-tools: Fix Released Status in lxc package in Ubuntu: Fix Committed Status in lxc source package in Xenial: Fix Released Status in lxc source package in Yakkety: Fix Released Status in lxc source package in Zesty: Fix Committed Bug description: ## SRU paperwork ### Rationale LXC 2.0.5 added support for Seccomp on the s390x architecture for those kernels that support it. Unfortunately the personality handling for s390x is wrong and results in the profile being setup twice, causing a failure to start the container. This effectively means that LXC 2.0.5 fails out of the box on s390x. ### Test case With LXC: - lxc-start -n some-container -F With LXD: - lxc start some-container ### Regression potential Our own testing shows that the fix works perfectly fine. The code change itself only affects s390x (under ifdef) so can't possibly affect the other architectures. The worst that can happen should this fix be wrong is either status quo (container won't start) or having the container start without seccomp support (status quo when compared to 2.0.4). ## Original bug report The s390x host used to Juju testing spontaneously broke today. The disk filled up, we restarted so that we could remove unused kernels. We discovered that lxc1 cannot create containers any more. $ sudo lxc-create -t ubuntu-cloud -n curtis -- -r xenial -a s390x $ sudo lxc-start -o lxc.log -n curtis lxc-start: tools/lxc_start.c: main: 344 The container failed to start. lxc-start: tools/lxc_start.c: main: 346 To get more details, run the container in foreground mode. lxc-start: tools/lxc_start.c: main: 348 Additional information can be obtained by setting the --logfile and --logpriority options. $ cat lxc.log lxc-start 20161020121833.069 ERRORlxc_seccomp - seccomp.c:get_new_ctx:224 - Seccomp error -17 (File exists) adding arch: 15 lxc-start 20161020121833.069 ERRORlxc_start - start.c:lxc_init:430 - failed loading seccomp policy lxc-start 20161020121833.069 ERRORlxc_start - start.c:__lxc_start:1313 - failed to initialize the container lxc-start 20161020121838.075 ERRORlxc_start_ui - tools/lxc_start.c:main:344 - The container failed to start. lxc-start 20161020121838.075 ERRORlxc_start_ui - tools/lxc_start.c:main:346 - To get more details, run the container in foreground mode. lxc-start 20161020121838.075 ERRORlxc_start_ui - tools/lxc_start.c:main:348 - Additional information can be obtained by setting the --logfile and --logpriority options. # sinzui: checking when s390x seccomp support was added to the # kernel, to see if it's just a missing config in our kernel that'd fix that # cleanly or if we'd need it backported to 4.4 which would be a bit more # annoying # sinzui: config-4.4.0-45-generic is what you're running right? # stgraber uname-a says 4.4.0-45-generic # stgraber> sinzui: you can workaround it by putting a file # with lxc.seccomp= # in /usr/share/lxc/config/common.conf.d/, that should get you going again WORK AROUND for LXC 1 # on the s390x-slave sudo vim /usr/share/lxc/config/common.conf.d/10-secomp-hack.conf $ cat /usr/share/lxc/config/common.conf.d/10-secomp-hack.conf # Advised to stgraber to add this file after seeing lxc-start fail with # lxc-start 20161020121833.069 ERRORlxc_seccomp - seccomp. lxc.seccomp= To manage notifications about this bug go to: https://bugs.launchpad.net/juju-ci-tools/+bug/1635639/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1635639] Re: Seccomp error with 2.0.5-0ubuntu1~ubuntu16.04.1 on s390x
** Changed in: juju-ci-tools Status: Fix Committed => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1635639 Title: Seccomp error with 2.0.5-0ubuntu1~ubuntu16.04.1 on s390x Status in juju-ci-tools: In Progress Status in lxc package in Ubuntu: New Bug description: The s390x host used to Juju testing spontaneously broke today. The disk filled up, we restarted so that we could remove unused kernels. We discovered that lxc1 cannot create containers any more. $ sudo lxc-create -t ubuntu-cloud -n curtis -- -r xenial -a s390x $ sudo lxc-start -o lxc.log -n curtis lxc-start: tools/lxc_start.c: main: 344 The container failed to start. lxc-start: tools/lxc_start.c: main: 346 To get more details, run the container in foreground mode. lxc-start: tools/lxc_start.c: main: 348 Additional information can be obtained by setting the --logfile and --logpriority options. $ cat lxc.log lxc-start 20161020121833.069 ERRORlxc_seccomp - seccomp.c:get_new_ctx:224 - Seccomp error -17 (File exists) adding arch: 15 lxc-start 20161020121833.069 ERRORlxc_start - start.c:lxc_init:430 - failed loading seccomp policy lxc-start 20161020121833.069 ERRORlxc_start - start.c:__lxc_start:1313 - failed to initialize the container lxc-start 20161020121838.075 ERRORlxc_start_ui - tools/lxc_start.c:main:344 - The container failed to start. lxc-start 20161020121838.075 ERRORlxc_start_ui - tools/lxc_start.c:main:346 - To get more details, run the container in foreground mode. lxc-start 20161020121838.075 ERRORlxc_start_ui - tools/lxc_start.c:main:348 - Additional information can be obtained by setting the --logfile and --logpriority options. # sinzui: checking when s390x seccomp support was added to the # kernel, to see if it's just a missing config in our kernel that'd fix that # cleanly or if we'd need it backported to 4.4 which would be a bit more # annoying # sinzui: config-4.4.0-45-generic is what you're running right? # stgraber uname-a says 4.4.0-45-generic # stgraber> sinzui: you can workaround it by putting a file # with lxc.seccomp= # in /usr/share/lxc/config/common.conf.d/, that should get you going again WORK AROUND for LXC 1 # on the s390x-slave sudo vim /usr/share/lxc/config/common.conf.d/10-secomp-hack.conf $ cat /usr/share/lxc/config/common.conf.d/10-secomp-hack.conf # Advised to stgraber to add this file after seeing lxc-start fail with # lxc-start 20161020121833.069 ERRORlxc_seccomp - seccomp. lxc.seccomp= To manage notifications about this bug go to: https://bugs.launchpad.net/juju-ci-tools/+bug/1635639/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1635639] Re: Seccomp error with 2.0.5-0ubuntu1~ubuntu16.04.1 on s390x
Current and new lxd containers are still broken. We see errors like this lxc start xenial-manual-a xenial-manual-b xenial-manual-c error: Error calling 'lxd forkstart xenial-manual-a /var/lib/lxd/containers /var/log/lxd/xenial-manual-a/lxc.conf': err='exit status 1' lxc 20161021035819.243 ERROR lxc_seccomp - seccomp.c:get_new_ctx:224 - Seccomp error -17 (File exists) adding arch: 15 lxc 20161021035819.243 ERROR lxc_start - start.c:lxc_init:430 - failed loading seccomp policy lxc 20161021035819.243 ERROR lxc_start - start.c:__lxc_start:1313 - failed to initialize the container ** Description changed: The s390x host used to Juju testing spontaneously broke today. The disk filled up, we restarted so that we could remove unused kernels. We discovered that lxc1 cannot create containers any more. $ sudo lxc-create -t ubuntu-cloud -n curtis -- -r xenial -a s390x $ sudo lxc-start -o lxc.log -n curtis lxc-start: tools/lxc_start.c: main: 344 The container failed to start. lxc-start: tools/lxc_start.c: main: 346 To get more details, run the container in foreground mode. lxc-start: tools/lxc_start.c: main: 348 Additional information can be obtained by setting the --logfile and --logpriority options. - $ cat lxc.log - lxc-start 20161020121833.069 ERRORlxc_seccomp - seccomp.c:get_new_ctx:224 - Seccomp error -17 (File exists) adding arch: 15 - lxc-start 20161020121833.069 ERRORlxc_start - start.c:lxc_init:430 - failed loading seccomp policy - lxc-start 20161020121833.069 ERRORlxc_start - start.c:__lxc_start:1313 - failed to initialize the container - lxc-start 20161020121838.075 ERRORlxc_start_ui - tools/lxc_start.c:main:344 - The container failed to start. - lxc-start 20161020121838.075 ERRORlxc_start_ui - tools/lxc_start.c:main:346 - To get more details, run the container in foreground mode. - lxc-start 20161020121838.075 ERRORlxc_start_ui - tools/lxc_start.c:main:348 - Additional information can be obtained by setting the --logfile and --logpriority options. - + $ cat lxc.log + lxc-start 20161020121833.069 ERRORlxc_seccomp - seccomp.c:get_new_ctx:224 - Seccomp error -17 (File exists) adding arch: 15 + lxc-start 20161020121833.069 ERRORlxc_start - start.c:lxc_init:430 - failed loading seccomp policy + lxc-start 20161020121833.069 ERRORlxc_start - start.c:__lxc_start:1313 - failed to initialize the container + lxc-start 20161020121838.075 ERRORlxc_start_ui - tools/lxc_start.c:main:344 - The container failed to start. + lxc-start 20161020121838.075 ERRORlxc_start_ui - tools/lxc_start.c:main:346 - To get more details, run the container in foreground mode. + lxc-start 20161020121838.075 ERRORlxc_start_ui - tools/lxc_start.c:main:348 - Additional information can be obtained by setting the --logfile and --logpriority options. # sinzui: checking when s390x seccomp support was added to the - # kernel, to see if it's just a missing config in our kernel that'd fix that - # cleanly or if we'd need it backported to 4.4 which would be a bit more + # kernel, to see if it's just a missing config in our kernel that'd fix that + # cleanly or if we'd need it backported to 4.4 which would be a bit more # annoying # sinzui: config-4.4.0-45-generic is what you're running right? # stgraber uname-a says 4.4.0-45-generic # stgraber> sinzui: you can workaround it by putting a file # with lxc.seccomp= # in /usr/share/lxc/config/common.conf.d/, that should get you going again - WORK AROUND + WORK AROUND for LXC 1 # on the s390x-slave sudo vim /usr/share/lxc/config/common.conf.d/10-secomp-hack.conf $ cat /usr/share/lxc/config/common.conf.d/10-secomp-hack.conf # Advised to stgraber to add this file after seeing lxc-start fail with # lxc-start 20161020121833.069 ERRORlxc_seccomp - seccomp. lxc.seccomp= -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1635639 Title: Seccomp error with 2.0.5-0ubuntu1~ubuntu16.04.1 on s390x Status in juju-ci-tools: Fix Committed Status in lxc package in Ubuntu: New Bug description: The s390x host used to Juju testing spontaneously broke today. The disk filled up, we restarted so that we could remove unused kernels. We discovered that lxc1 cannot create containers any more. $ sudo lxc-create -t ubuntu-cloud -n curtis -- -r xenial -a s390x $ sudo lxc-start -o lxc.log -n curtis lxc-start: tools/lxc_start.c: main: 344 The container failed to start. lxc-start: tools/lxc_start.c: main: 346 To get more details, run the container in foreground mode. lxc-start: tools/lxc_start.c: main: 348 Additional information can be obtained by setting the --logfile and --logpriority options. $ cat lxc.log lxc-start 20161020121833.069 ERRORlxc_seccomp -
[Touch-packages] [Bug 1635639] [NEW] Seccomp error with 2.0.5-0ubuntu1~ubuntu16.04.1 on s390x
Public bug reported: The s390x host used to Juju testing spontaneously broke today. The disk filled up, we restarted so that we could remove unused kernels. We discovered that lxc1 cannot create containers any more. $ sudo lxc-create -t ubuntu-cloud -n curtis -- -r xenial -a s390x $ sudo lxc-start -o lxc.log -n curtis lxc-start: tools/lxc_start.c: main: 344 The container failed to start. lxc-start: tools/lxc_start.c: main: 346 To get more details, run the container in foreground mode. lxc-start: tools/lxc_start.c: main: 348 Additional information can be obtained by setting the --logfile and --logpriority options. $ cat lxc.log lxc-start 20161020121833.069 ERRORlxc_seccomp - seccomp.c:get_new_ctx:224 - Seccomp error -17 (File exists) adding arch: 15 lxc-start 20161020121833.069 ERRORlxc_start - start.c:lxc_init:430 - failed loading seccomp policy lxc-start 20161020121833.069 ERRORlxc_start - start.c:__lxc_start:1313 - failed to initialize the container lxc-start 20161020121838.075 ERRORlxc_start_ui - tools/lxc_start.c:main:344 - The container failed to start. lxc-start 20161020121838.075 ERRORlxc_start_ui - tools/lxc_start.c:main:346 - To get more details, run the container in foreground mode. lxc-start 20161020121838.075 ERRORlxc_start_ui - tools/lxc_start.c:main:348 - Additional information can be obtained by setting the --logfile and --logpriority options. # sinzui: checking when s390x seccomp support was added to the # kernel, to see if it's just a missing config in our kernel that'd fix that # cleanly or if we'd need it backported to 4.4 which would be a bit more # annoying # sinzui: config-4.4.0-45-generic is what you're running right? # stgraber uname-a says 4.4.0-45-generic # stgraber> sinzui: you can workaround it by putting a file # with lxc.seccomp= # in /usr/share/lxc/config/common.conf.d/, that should get you going again WORK AROUND # on the s390x-slave sudo vim /usr/share/lxc/config/common.conf.d/10-secomp-hack.conf $ cat /usr/share/lxc/config/common.conf.d/10-secomp-hack.conf # Advised to stgraber to add this file after seeing lxc-start fail with # lxc-start 20161020121833.069 ERRORlxc_seccomp - seccomp. lxc.seccomp= ** Affects: juju-ci-tools Importance: Critical Assignee: Curtis Hovey (sinzui) Status: Fix Committed ** Affects: lxc (Ubuntu) Importance: Undecided Status: New ** Tags: jujuqa lxd regression s390x ** Also affects: lxc Importance: Undecided Status: New ** Project changed: lxc => juju-ci-tools ** Changed in: juju-ci-tools Status: New => Fix Committed ** Changed in: juju-ci-tools Importance: Undecided => Critical ** Changed in: juju-ci-tools Assignee: (unassigned) => Curtis Hovey (sinzui) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1635639 Title: Seccomp error with 2.0.5-0ubuntu1~ubuntu16.04.1 on s390x Status in juju-ci-tools: Fix Committed Status in lxc package in Ubuntu: New Bug description: The s390x host used to Juju testing spontaneously broke today. The disk filled up, we restarted so that we could remove unused kernels. We discovered that lxc1 cannot create containers any more. $ sudo lxc-create -t ubuntu-cloud -n curtis -- -r xenial -a s390x $ sudo lxc-start -o lxc.log -n curtis lxc-start: tools/lxc_start.c: main: 344 The container failed to start. lxc-start: tools/lxc_start.c: main: 346 To get more details, run the container in foreground mode. lxc-start: tools/lxc_start.c: main: 348 Additional information can be obtained by setting the --logfile and --logpriority options. $ cat lxc.log lxc-start 20161020121833.069 ERRORlxc_seccomp - seccomp.c:get_new_ctx:224 - Seccomp error -17 (File exists) adding arch: 15 lxc-start 20161020121833.069 ERRORlxc_start - start.c:lxc_init:430 - failed loading seccomp policy lxc-start 20161020121833.069 ERRORlxc_start - start.c:__lxc_start:1313 - failed to initialize the container lxc-start 20161020121838.075 ERRORlxc_start_ui - tools/lxc_start.c:main:344 - The container failed to start. lxc-start 20161020121838.075 ERRORlxc_start_ui - tools/lxc_start.c:main:346 - To get more details, run the container in foreground mode. lxc-start 20161020121838.075 ERRORlxc_start_ui - tools/lxc_start.c:main:348 - Additional information can be obtained by setting the --logfile and --logpriority options. # sinzui: checking when s390x seccomp support was added to the # kernel, to see if it's just a missing config in our kernel that'd fix that # cleanly or if we'd need it backported to 4.4 which would be a bit more # annoying # sinzui: config-4.4.0-45-generic is what you're running right? # stgraber uname-a says 4.4.0-45-generic # stgrab
[Touch-packages] [Bug 1596638] Re: python2 cannot import lsb_release on yakkety and now xenial
This issue is now seen in xenial. This was not a problem a few hours ago. We can see on xenial now. These versions 9.20160110ubuntu4 and 9.20160110ubuntu0.1 remove the py2 module, but do not provide a py2 package to install. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lsb in Ubuntu. https://bugs.launchpad.net/bugs/1596638 Title: python2 cannot import lsb_release on yakkety and now xenial Status in lsb package in Ubuntu: Confirmed Bug description: python2 cannot import lsb_release on yakkety. `locate` shows "lsb- release" installed several files, but /usr/lib/python2.7/dist-packages/lsb_release.py is missing from disk. This was seen on an aws instance provisioned using the 20160526 daily image. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1596638/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1596638] Re: python2 cannot import lsb_release on yakkety and now xenial
** Summary changed: - python2 cannot import lsb_release on yakkety + python2 cannot import lsb_release on yakkety and now xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lsb in Ubuntu. https://bugs.launchpad.net/bugs/1596638 Title: python2 cannot import lsb_release on yakkety and now xenial Status in lsb package in Ubuntu: Confirmed Bug description: python2 cannot import lsb_release on yakkety. `locate` shows "lsb- release" installed several files, but /usr/lib/python2.7/dist-packages/lsb_release.py is missing from disk. This was seen on an aws instance provisioned using the 20160526 daily image. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1596638/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1596638] [NEW] python2 cannot import lsb_release on yakkety
Public bug reported: python2 cannot import lsb_release on yakkety. `locate` shows "lsb- release" installed several files, but /usr/lib/python2.7/dist-packages/lsb_release.py is missing from disk. This was seen on an aws instance provisioned using the 20160526 daily image. ** Affects: lsb (Ubuntu) Importance: Undecided Status: New ** Tags: jujuqa -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lsb in Ubuntu. https://bugs.launchpad.net/bugs/1596638 Title: python2 cannot import lsb_release on yakkety Status in lsb package in Ubuntu: New Bug description: python2 cannot import lsb_release on yakkety. `locate` shows "lsb- release" installed several files, but /usr/lib/python2.7/dist-packages/lsb_release.py is missing from disk. This was seen on an aws instance provisioned using the 20160526 daily image. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1596638/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1492088] Re: juju bootstrap fails inside a wily container
** Changed in: juju-core
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1492088
Title:
juju bootstrap fails inside a wily container
Status in juju-core:
Fix Released
Status in systemd package in Ubuntu:
Incomplete
Bug description:
Running juju 1.24.5 and attempting to do a local bootstrap inside a
wily container fails with the following:
[DEBUG: 09-03 20:49:56, container.py:139] Error with command: [Output]
'2015-09-03 20:49:35 INFO juju.cmd supercommand.go:37 running juju
[1.24.5-wily-amd64 gc]
2015-09-03 20:49:35 DEBUG juju.environs.configstore disk.go:109 Made
dir /home/ubuntu/.cloud-install/juju/environments
2015-09-03 20:49:35 INFO juju.provider.local environprovider.go:245
checking state port
2015-09-03 20:49:35 INFO juju.provider.local environprovider.go:245
checking API port
2015-09-03 20:49:35 INFO juju.provider.local environprovider.go:38
opening environment "local"
2015-09-03 20:49:35 DEBUG juju.container.kvm kvm.go:71 kvm-ok output:
INFO: /dev/kvm exists
KVM acceleration can be used
2015-09-03 20:49:35 DEBUG juju.provider.local environ.go:325 found
"10.0.6.1" as address for "lxcbr0"
2015-09-03 20:49:35 DEBUG juju.environs.configstore disk.go:308
writing jenv file
2015-09-03 20:49:35 DEBUG juju.environs.configstore disk.go:432
writing jenv file to /home/ubuntu/.cloud-
install/juju/environments/local.jenv
2015-09-03 20:49:35 INFO juju.network network.go:194 setting prefer-
ipv6 to false
2015-09-03 20:49:35 INFO juju.cmd cmd.go:113 Bootstrapping environment
"local"
2015-09-03 20:49:35 DEBUG juju.environs.bootstrap bootstrap.go:98
environment "local" supports service/machine networks: false
2015-09-03 20:49:35 DEBUG juju.environs.bootstrap bootstrap.go:100
network management by juju enabled: true
2015-09-03 20:49:35 DEBUG juju.provider.local environ.go:325 found
"10.0.6.1" as address for "lxcbr0"
2015-09-03 20:49:35 INFO juju.cmd cmd.go:113 Starting new instance for
initial state server
2015-09-03 20:49:35 INFO juju.environs.bootstrap bootstrap.go:184
newest version: 1.24.5.1
2015-09-03 20:49:36 INFO juju.environs.bootstrap bootstrap.go:212
picked bootstrap tools version: 1.24.5.1
2015-09-03 20:49:36 INFO juju.cmd cmd.go:113 Building tools to upload
(1.24.5.1-wily-amd64)
2015-09-03 20:49:36 DEBUG juju.environs.sync sync.go:304 Building
tools
2015-09-03 20:49:36 DEBUG juju.environs.tools build.go:122 looking
for: juju
2015-09-03 20:49:36 DEBUG juju.environs.tools build.go:161 checking:
/usr/bin/jujud
2015-09-03 20:49:36 INFO juju.environs.tools build.go:167 found
existing jujud
2015-09-03 20:49:36 INFO juju.environs.tools build.go:177 target: /tmp
/juju-tools782467678/jujud
2015-09-03 20:49:36 DEBUG juju.environs.tools build.go:232 forcing
version to 1.24.5.1
2015-09-03 20:49:36 DEBUG juju.environs.tools build.go:38 adding
entry: {Name:"FORCE-VERSION", Mode:436, Uid:0, Gid:0,
Size:8, ModTime:time.Time{sec:63576910176, nsec:90190527,
loc:(*time.Location)(0x2c9b140)}, Typeflag:0x30, Linkname:"",
Uname:"ubuntu", Gname:"ubuntu", Devmajor:0, Devminor:0,
AccessTime:time.Time{sec:63576910176, nsec:90190527,
loc:(*time.Location)(0x2c9b140)},
ChangeTime:time.Time{sec:63576910176, nsec:90190527,
loc:(*time.Location)(0x2c9b140)}, Xattrs:map[string]string(nil)}
2015-09-03 20:49:36 DEBUG juju.environs.tools build.go:38 adding
entry: {Name:"jujud", Mode:493, Uid:0, Gid:0,
Size:67623560, ModTime:time.Time{sec:63576910176, nsec:90190527,
loc:(*time.Location)(0x2c9b140)}, Typeflag:0x30, Linkname:"",
Uname:"ubuntu", Gname:"ubuntu", Devmajor:0, Devminor:0,
AccessTime:time.Time{sec:63576910176, nsec:90190527,
loc:(*time.Location)(0x2c9b140)},
ChangeTime:time.Time{sec:63576910176, nsec:90190527,
loc:(*time.Location)(0x2c9b140)}, Xattrs:map[string]string(nil)}
2015-09-03 20:49:42 INFO juju.environs.sync sync.go:323 built tools
1.24.5.1-wily-amd64 (13769kB)
2015-09-03 20:49:42 INFO juju.cmd cmd.go:113 Installing Juju agent on
bootstrap instance
2015-09-03 20:49:42 DEBUG juju.cloudconfig.instancecfg
instancecfg.go:521 Setting numa ctl preference to false
2015-09-03 20:49:42 INFO juju.provider.local environ.go:156 local
provider; disabling refreshing OS updates.
2015-09-03 20:49:42 INFO juju.provider.local environ.go:162 local
provider; disabling OS upgrades.
Logging to /home/ubuntu/.cloud-install/juju/local/cloud-init-
output.log on remote host
Installing package: curl
Installing package: cpu-checker
Installing package: bridge-utils
Installing package: rsyslog-gnutls
Installing package: cloud-utils
Installing package: cloud-image-utils
Installing package: tmux
Bootstrapping Juju machine agent
Reading package lists...
Building
[Touch-packages] [Bug 1559169] Re: containers no longer start after upgrade to 2.0.0~rc11-0ubuntu1
This was also seen by the in Juju CI on the wily hosts that pull lxd/lxc packages from the lxd ppa. We downgrades the wily machines to packages from wily-updates to get lxc working again. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1559169 Title: containers no longer start after upgrade to 2.0.0~rc11-0ubuntu1 Status in lxc package in Ubuntu: Confirmed Bug description: Running xenial, after upgrading to lxc 2.0.0~rc11-0ubuntu1, I can't start containers any more: $ sudo lxc-start -F -n precise-lptest-base ln: failed to create symbolic link '/usr/lib/x86_64-linux-gnu/lxc/sys/fs/cgroup/cpu/cpu,cpuacct': Read-only file system lxc-start: conf.c: run_buffer: 347 Script exited with status 1 lxc-start: conf.c: lxc_setup: 3750 failed to run mount hooks for container 'precise-lptest-base'. lxc-start: start.c: do_start: 793 failed to setup the container lxc-start: sync.c: __sync_wait: 51 invalid sequence number 1. expected 2 lxc-start: start.c: __lxc_start: 1286 failed to spawn 'precise-lptest-base' lxc-start: lxc_start.c: main: 344 The container failed to start. lxc-start: lxc_start.c: main: 348 Additional information can be obtained by setting the --logfile and --logpriority options. Downgrading all the lxc binary packages I have installed to 2.0.0~rc10-0ubuntu2 makes things work again. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1559169/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1559169] Re: containers no longer start after upgrade to 2.0.0~rc11-0ubuntu1
This is the error jenkins@wily-slave:~$ sudo lxc-start -n curtis -F ln: failed to create symbolic link ‘/usr/lib/x86_64-linux-gnu/lxc/sys/fs/cgroup/cpu/cpu,cpuacct’: Read-only file system lxc-start: conf.c: run_buffer: 347 Script exited with status 1 lxc-start: conf.c: lxc_setup: 3750 failed to run mount hooks for container 'curtis'. lxc-start: start.c: do_start: 793 failed to setup the container lxc-start: sync.c: __sync_wait: 51 invalid sequence number 1. expected 2 lxc-start: start.c: __lxc_start: 1286 failed to spawn 'curtis' lxc-start: lxc_start.c: main: 344 The container failed to start. lxc-start: lxc_start.c: main: 348 Additional information can be obtained by setting the --logfile and --logpriority options. Attached is the log of what happened. The wily-slave host uses the lxd ppa. it has a lower priority. These packages were installed and get updates outside of regular wily-updates: sudo apt-get install --no-install-recommends lxc=2.0* lxc-templates=2.0* lxc1=2.0* python3-lxc=2.0* liblxc1=2.0* jenkins@wily-slave:~$ apt-cache policy lxc lxc: Installed: 2.0.0~rc11-0ubuntu1~ubuntu15.10.1~ppa1 Candidate: 2.0.0~rc11-0ubuntu1~ubuntu15.10.1~ppa1 Package pin: 2.0.0~rc11-0ubuntu1~ubuntu15.10.1~ppa1 Version table: *** 2.0.0~rc11-0ubuntu1~ubuntu15.10.1~ppa1 500 200 http://ppa.launchpad.net/ubuntu-lxc/lxd-stable/ubuntu/ wily/main amd64 Packages 100 /var/lib/dpkg/status 1.1.5-0ubuntu0.15.10.3 500 500 http://us-sw-1.joyent.archive.ubuntu.com/ubuntu/ wily-updates/main amd64 Packages 1.1.4-0ubuntu1 500 500 http://us-sw-1.joyent.archive.ubuntu.com/ubuntu/ wily/main amd64 Packages jenkins@wily-slave:~$ apt-cache policy lxcfs lxcfs: Installed: 2.0.0~rc6-0ubuntu1~ubuntu15.10.1~ppa1 Candidate: 2.0.0~rc6-0ubuntu1~ubuntu15.10.1~ppa1 Package pin: 2.0.0~rc6-0ubuntu1~ubuntu15.10.1~ppa1 Version table: *** 2.0.0~rc6-0ubuntu1~ubuntu15.10.1~ppa1 500 200 http://ppa.launchpad.net/ubuntu-lxc/lxd-stable/ubuntu/ wily/main amd64 Packages 100 /var/lib/dpkg/status 0.10-0ubuntu2.3 500 400 http://archive.ubuntu.com/ubuntu/ wily-proposed/main amd64 Packages 0.10-0ubuntu2.1 500 500 http://us-sw-1.joyent.archive.ubuntu.com/ubuntu/ wily-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu/ wily-security/main amd64 Packages 0.10-0ubuntu2 500 500 http://us-sw-1.joyent.archive.ubuntu.com/ubuntu/ wily/main amd64 Packages ** Attachment added: "log of starting a container" https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1559169/+attachment/4603531/+files/curtis.log -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1559169 Title: containers no longer start after upgrade to 2.0.0~rc11-0ubuntu1 Status in lxc package in Ubuntu: Triaged Bug description: Running xenial, after upgrading to lxc 2.0.0~rc11-0ubuntu1, I can't start containers any more: $ sudo lxc-start -F -n precise-lptest-base ln: failed to create symbolic link '/usr/lib/x86_64-linux-gnu/lxc/sys/fs/cgroup/cpu/cpu,cpuacct': Read-only file system lxc-start: conf.c: run_buffer: 347 Script exited with status 1 lxc-start: conf.c: lxc_setup: 3750 failed to run mount hooks for container 'precise-lptest-base'. lxc-start: start.c: do_start: 793 failed to setup the container lxc-start: sync.c: __sync_wait: 51 invalid sequence number 1. expected 2 lxc-start: start.c: __lxc_start: 1286 failed to spawn 'precise-lptest-base' lxc-start: lxc_start.c: main: 344 The container failed to start. lxc-start: lxc_start.c: main: 348 Additional information can be obtained by setting the --logfile and --logpriority options. Downgrading all the lxc binary packages I have installed to 2.0.0~rc10-0ubuntu2 makes things work again. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1559169/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1403955] Re: DHCP's "Option interface-mtu 9000" is being ignored on bridge interface br0
** Changed in: juju-core
Milestone: 1.23-beta1 => None
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1403955
Title:
DHCP's "Option interface-mtu 9000" is being ignored on bridge
interface br0
Status in juju-core:
Triaged
Status in isc-dhcp package in Ubuntu:
Confirmed
Bug description:
In an env with jumbo frames enabled, and using MAAS as DHCP server,
the client receives the following IPv4 lease:
$ cat /var/lib/dhcp/dhclient.br0.leases
lease {
interface "br0";
fixed-address 10.230.20.26;
filename "pxelinux.0";
option subnet-mask 255.255.248.0;
option dhcp-lease-time 43200;
option routers 10.230.16.1;
option dhcp-message-type 5;
option dhcp-server-identifier 10.230.20.1;
option domain-name-servers 10.230.20.1;
option interface-mtu 9000;
option broadcast-address 10.230.23.255;
option domain-name "ctsstack.qa.1ss";
renew 3 2014/12/17 16:48:15;
rebind 3 2014/12/17 21:52:09;
expire 3 2014/12/17 23:22:09;
}
The interfaces show the following config after boot:
$ ifconfig br0
br0 Link encap:Ethernet HWaddr a0:d3:c1:01:9d:58
inet addr:10.230.20.26 Bcast:10.230.23.255 Mask:255.255.248.0
inet6 addr: fe80::a2d3:c1ff:fe01:9d58/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:530530 errors:0 dropped:0 overruns:0 frame:0
TX packets:1591569 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:68713489 (68.7 MB) TX bytes:213710979 (213.7 MB)
$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr a0:d3:c1:01:9d:58
inet6 addr: fe80::a2d3:c1ff:fe01:9d58/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10539274 errors:0 dropped:3394 overruns:0 frame:454
TX packets:2627412 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2320560616 (2.3 GB) TX bytes:3562885157 (3.5 GB)
Interrupt:32
"option interface-mtu 9000;" from the lease file is being ignored by br0.
Could it be related to eth0 MTU size? If that's the case, shouldn't both
interfaces be updated?
Other info:
$ brctl show br0
bridge name bridge id STP enabled interfaces
br0 8000.a0d3c1019d58 no eth0
$ cat /etc/network/eth0.config
iface eth0 inet manual
auto br0
iface br0 inet dhcp
bridge_ports eth0
To manage notifications about this bug go to:
https://bugs.launchpad.net/juju-core/+bug/1403955/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1508577] Re: [wily] installing juju-local on ARM64 failed. broken apt dependency
** Also affects: lxc (Ubuntu)
Importance: Undecided
Status: New
** Changed in: juju-core
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1508577
Title:
[wily] installing juju-local on ARM64 failed. broken apt dependency
Status in juju-core:
Invalid
Status in lxc package in Ubuntu:
New
Bug description:
Installing juju-local on ARM64 fails due to broken dependency.
running apt-get install -f does not solve this.
Setting up lxc (1.1.4-0ubuntu1) ...
Job for lxc-net.service failed because the control process exited with error
code. See "systemctl status lxc-net.service" and "journalctl -xe" for details.
invoke-rc.d: initscript lxc-net, action "start" failed.
dpkg: error processing package lxc (--configure):
subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of lxc-templates:
lxc-templates depends on lxc (>= 0.8.0~rc1-4ubuntu43); however:
Package lxc is not configured yet.
dpkg: error processing package lxc-templates (--configure):
dependency problems - leaving unconfigured
Setting up lxcfs (0.10-0ubuntu2) ...
update-alternatives: using /usr/lib/juju-1.24.6/bin/juju to provide
/usr/bin/juju (juju) in auto mode
Setting up rsyslog-gnutls (8.12.0-1ubuntu2) ...
dpkg: dependency problems prevent configuration of juju-local:
juju-local depends on lxc (>= 1.0.0~alpha1-0ubuntu14); however:
Package lxc is not configured yet.
juju-local depends on lxc-templates; however:
Package lxc-templates is not configured yet.
dpkg: error processing package juju-local (--configure):
dependency problems - leaving unconfigured
ubuntu@machine:~$ sudo apt-get install -f
sudo: unable to resolve host bandera
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer
required:
libdw1 libelf1 libunwind8
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 8 not upgraded.
3 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Setting up lxc (1.1.4-0ubuntu1) ...
Job for lxc-net.service failed because the control process exited with error
code. See "systemctl status lxc-net.service" and "journalctl -xe" for details.
invoke-rc.d: initscript lxc-net, action "start" failed.
dpkg: error processing package lxc (--configure):
subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of lxc-templates:
lxc-templates depends on lxc (>= 0.8.0~rc1-4ubuntu43); however:
Package lxc is not configured yet.
dpkg: error processing package lxc-templates (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of juju-local:
juju-local depends on lxc (>= 1.0.0~alpha1-0ubuntu14); however:
Package lxc is not configured yet.
juju-local depends on lxc-templates; however:
Package lxc-templates is not configured yet.
dpkg: error processing package juju-local (--configure):
dependency problems - leaving unconfigured
Errors were encountered while processing:
lxc
lxc-templates
juju-local
E: Sub-process /usr/bin/dpkg returned an error code (1)
ubuntu@machine:~$
To manage notifications about this bug go to:
https://bugs.launchpad.net/juju-core/+bug/1508577/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1480310] Re: systemctl link request failed for service FOO: Unit name FOO is not valid.
Juju CI confirms this is fixed: http://reports.vapour.ws/releases/3016/job/local-deploy-wily-amd64/attempt/297 ** Changed in: juju-core Status: Triaged = Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1480310 Title: systemctl link request failed for service FOO: Unit name FOO is not valid. Status in juju-core: Fix Released Status in systemd package in Ubuntu: Fix Released Bug description: As seen in http://reports.vapour.ws/releases/2936/job/local-deploy-wily-amd64/attempt/136 Juju cannot bootstrap on wily because ERROR juju.service.systemd service.go:149 dbus link request failed for service juju-db-jenkins-local-deploy-wily-amd64: Unit name /var/lib/juju/init/juju-db-jenkins-local-deploy-wily-amd64/juju-db-jenkins-local-deploy-wily-amd64.service is not valid. This error first occurred after the wily-slave got package updates. The released jujus get the same errors as the jujus under test. This issue is probably an Ubuntu packaging break. I am making the test non-voting since we can see table 1.24.3 no longer works. To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1480310/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1480310] Re: systemctl link request failed for service FOO: Unit name FOO is not valid.
** Changed in: juju-core Milestone: 1.25-alpha1 = 1.25-beta1 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1480310 Title: systemctl link request failed for service FOO: Unit name FOO is not valid. Status in juju-core: Triaged Status in systemd package in Ubuntu: Fix Committed Bug description: As seen in http://reports.vapour.ws/releases/2936/job/local-deploy-wily-amd64/attempt/136 Juju cannot bootstrap on wily because ERROR juju.service.systemd service.go:149 dbus link request failed for service juju-db-jenkins-local-deploy-wily-amd64: Unit name /var/lib/juju/init/juju-db-jenkins-local-deploy-wily-amd64/juju-db-jenkins-local-deploy-wily-amd64.service is not valid. This error first occurred after the wily-slave got package updates. The released jujus get the same errors as the jujus under test. This issue is probably an Ubuntu packaging break. I am making the test non-voting since we can see table 1.24.3 no longer works. To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1480310/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1480310] Re: systemctl link request failed for service FOO: Unit name FOO is not valid.
The duplicate bug confirms what we are seeing in CI wily + 1.24.5: Failed to execute operation: Unit name /etc/systemd/system/juju-clean-shutdown.service is not valid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1480310 Title: systemctl link request failed for service FOO: Unit name FOO is not valid. Status in juju-core: Triaged Status in systemd package in Ubuntu: Fix Released Bug description: As seen in http://reports.vapour.ws/releases/2936/job/local-deploy-wily-amd64/attempt/136 Juju cannot bootstrap on wily because ERROR juju.service.systemd service.go:149 dbus link request failed for service juju-db-jenkins-local-deploy-wily-amd64: Unit name /var/lib/juju/init/juju-db-jenkins-local-deploy-wily-amd64/juju-db-jenkins-local-deploy-wily-amd64.service is not valid. This error first occurred after the wily-slave got package updates. The released jujus get the same errors as the jujus under test. This issue is probably an Ubuntu packaging break. I am making the test non-voting since we can see table 1.24.3 no longer works. To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1480310/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1480310] Re: systemctl link request failed for service FOO: Unit name FOO is not valid.
We are still seeing this issue after getting this fix and rebooting the machine: jenkins@wily-slave:~$ apt-cache policy systemd systemd: Installed: 224-1ubuntu3 Candidate: 224-1ubuntu3 Version table: *** 224-1ubuntu3 0 500 http://archive.ubuntu.com/ubuntu/ wily/main amd64 Packages 100 /var/lib/dpkg/status 2015-08-14 13:19:28 ERROR juju.service.systemd service.go:452 failed to install service juju-db-jenkins-local-deploy-wily-amd64: dbus enable request failed for service juju-db-jenkins-local-deploy-wily-amd64: Unit name /var/lib/juju/init/juju-db-jenkins-local-deploy-wily-amd64/juju-db-jenkins-local-deploy-wily-amd64.service is not valid. 2015-08-14 13:19:28 ERROR juju.cmd supercommand.go:429 dbus enable request failed for service juju-db-jenkins-local-deploy-wily-amd64: Unit name /var/lib/juju/init/juju-db-jenkins-local-deploy-wily-amd64/juju-db-jenkins-local-deploy-wily-amd64.service is not valid. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1480310 Title: systemctl link request failed for service FOO: Unit name FOO is not valid. Status in juju-core: Triaged Status in systemd package in Ubuntu: Fix Released Bug description: As seen in http://reports.vapour.ws/releases/2936/job/local-deploy-wily-amd64/attempt/136 Juju cannot bootstrap on wily because ERROR juju.service.systemd service.go:149 dbus link request failed for service juju-db-jenkins-local-deploy-wily-amd64: Unit name /var/lib/juju/init/juju-db-jenkins-local-deploy-wily-amd64/juju-db-jenkins-local-deploy-wily-amd64.service is not valid. This error first occurred after the wily-slave got package updates. The released jujus get the same errors as the jujus under test. This issue is probably an Ubuntu packaging break. I am making the test non-voting since we can see table 1.24.3 no longer works. To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1480310/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1480310] Re: dbus link request failed for service FOO: Unit name FOO is not valid.
This bug blocks bug 1481556 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1480310 Title: dbus link request failed for service FOO: Unit name FOO is not valid. Status in juju-core: Triaged Status in systemd package in Ubuntu: Confirmed Bug description: As seen in http://reports.vapour.ws/releases/2936/job/local-deploy-wily-amd64/attempt/136 Juju cannot bootstrap on wily because ERROR juju.service.systemd service.go:149 dbus link request failed for service juju-db-jenkins-local-deploy-wily-amd64: Unit name /var/lib/juju/init/juju-db-jenkins-local-deploy-wily-amd64/juju-db-jenkins-local-deploy-wily-amd64.service is not valid. This error first occurred after the wily-slave got package updates. The released jujus get the same errors as the jujus under test. This issue is probably an Ubuntu packaging break. I am making the test non-voting since we can see table 1.24.3 no longer works. To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1480310/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1480310] Re: dbus link request failed for service FOO: Unit name FOO is not valid.
** Also affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1480310 Title: dbus link request failed for service FOO: Unit name FOO is not valid. Status in juju-core: Triaged Status in systemd package in Ubuntu: New Bug description: As seen in http://reports.vapour.ws/releases/2936/job/local-deploy-wily-amd64/attempt/136 Juju cannot bootstrap on wily because ERROR juju.service.systemd service.go:149 dbus link request failed for service juju-db-jenkins-local-deploy-wily-amd64: Unit name /var/lib/juju/init/juju-db-jenkins-local-deploy-wily-amd64/juju-db-jenkins-local-deploy-wily-amd64.service is not valid. This error first occurred after the wily-slave got package updates. The released jujus get the same errors as the jujus under test. This issue is probably an Ubuntu packaging break. I am making the test non-voting since we can see table 1.24.3 no longer works. To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1480310/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1480310] Re: dbus link request failed for service FOO: Unit name FOO is not valid.
** Changed in: systemd (Ubuntu) Status: New = Confirmed ** Changed in: juju-core Importance: Critical = High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1480310 Title: dbus link request failed for service FOO: Unit name FOO is not valid. Status in juju-core: Triaged Status in systemd package in Ubuntu: Confirmed Bug description: As seen in http://reports.vapour.ws/releases/2936/job/local-deploy-wily-amd64/attempt/136 Juju cannot bootstrap on wily because ERROR juju.service.systemd service.go:149 dbus link request failed for service juju-db-jenkins-local-deploy-wily-amd64: Unit name /var/lib/juju/init/juju-db-jenkins-local-deploy-wily-amd64/juju-db-jenkins-local-deploy-wily-amd64.service is not valid. This error first occurred after the wily-slave got package updates. The released jujus get the same errors as the jujus under test. This issue is probably an Ubuntu packaging break. I am making the test non-voting since we can see table 1.24.3 no longer works. To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1480310/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1403955] Re: DHCP's Option interface-mtu 9000 is being ignored on bridge interface br0
** Changed in: juju-core
Status: Fix Released = Triaged
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1403955
Title:
DHCP's Option interface-mtu 9000 is being ignored on bridge
interface br0
Status in juju-core:
Triaged
Status in isc-dhcp package in Ubuntu:
Confirmed
Bug description:
In an env with jumbo frames enabled, and using MAAS as DHCP server,
the client receives the following IPv4 lease:
$ cat /var/lib/dhcp/dhclient.br0.leases
lease {
interface br0;
fixed-address 10.230.20.26;
filename pxelinux.0;
option subnet-mask 255.255.248.0;
option dhcp-lease-time 43200;
option routers 10.230.16.1;
option dhcp-message-type 5;
option dhcp-server-identifier 10.230.20.1;
option domain-name-servers 10.230.20.1;
option interface-mtu 9000;
option broadcast-address 10.230.23.255;
option domain-name ctsstack.qa.1ss;
renew 3 2014/12/17 16:48:15;
rebind 3 2014/12/17 21:52:09;
expire 3 2014/12/17 23:22:09;
}
The interfaces show the following config after boot:
$ ifconfig br0
br0 Link encap:Ethernet HWaddr a0:d3:c1:01:9d:58
inet addr:10.230.20.26 Bcast:10.230.23.255 Mask:255.255.248.0
inet6 addr: fe80::a2d3:c1ff:fe01:9d58/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:530530 errors:0 dropped:0 overruns:0 frame:0
TX packets:1591569 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:68713489 (68.7 MB) TX bytes:213710979 (213.7 MB)
$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr a0:d3:c1:01:9d:58
inet6 addr: fe80::a2d3:c1ff:fe01:9d58/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10539274 errors:0 dropped:3394 overruns:0 frame:454
TX packets:2627412 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2320560616 (2.3 GB) TX bytes:3562885157 (3.5 GB)
Interrupt:32
option interface-mtu 9000; from the lease file is being ignored by br0.
Could it be related to eth0 MTU size? If that's the case, shouldn't both
interfaces be updated?
Other info:
$ brctl show br0
bridge name bridge id STP enabled interfaces
br0 8000.a0d3c1019d58 no eth0
$ cat /etc/network/eth0.config
iface eth0 inet manual
auto br0
iface br0 inet dhcp
bridge_ports eth0
To manage notifications about this bug go to:
https://bugs.launchpad.net/juju-core/+bug/1403955/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1403955] Re: DHCP's Option interface-mtu 9000 is being ignored on bridge interface br0
** Changed in: juju-core
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1403955
Title:
DHCP's Option interface-mtu 9000 is being ignored on bridge
interface br0
Status in juju-core:
Fix Released
Status in isc-dhcp package in Ubuntu:
Confirmed
Bug description:
In an env with jumbo frames enabled, and using MAAS as DHCP server,
the client receives the following IPv4 lease:
$ cat /var/lib/dhcp/dhclient.br0.leases
lease {
interface br0;
fixed-address 10.230.20.26;
filename pxelinux.0;
option subnet-mask 255.255.248.0;
option dhcp-lease-time 43200;
option routers 10.230.16.1;
option dhcp-message-type 5;
option dhcp-server-identifier 10.230.20.1;
option domain-name-servers 10.230.20.1;
option interface-mtu 9000;
option broadcast-address 10.230.23.255;
option domain-name ctsstack.qa.1ss;
renew 3 2014/12/17 16:48:15;
rebind 3 2014/12/17 21:52:09;
expire 3 2014/12/17 23:22:09;
}
The interfaces show the following config after boot:
$ ifconfig br0
br0 Link encap:Ethernet HWaddr a0:d3:c1:01:9d:58
inet addr:10.230.20.26 Bcast:10.230.23.255 Mask:255.255.248.0
inet6 addr: fe80::a2d3:c1ff:fe01:9d58/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:530530 errors:0 dropped:0 overruns:0 frame:0
TX packets:1591569 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:68713489 (68.7 MB) TX bytes:213710979 (213.7 MB)
$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr a0:d3:c1:01:9d:58
inet6 addr: fe80::a2d3:c1ff:fe01:9d58/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10539274 errors:0 dropped:3394 overruns:0 frame:454
TX packets:2627412 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2320560616 (2.3 GB) TX bytes:3562885157 (3.5 GB)
Interrupt:32
option interface-mtu 9000; from the lease file is being ignored by br0.
Could it be related to eth0 MTU size? If that's the case, shouldn't both
interfaces be updated?
Other info:
$ brctl show br0
bridge name bridge id STP enabled interfaces
br0 8000.a0d3c1019d58 no eth0
$ cat /etc/network/eth0.config
iface eth0 inet manual
auto br0
iface br0 inet dhcp
bridge_ports eth0
To manage notifications about this bug go to:
https://bugs.launchpad.net/juju-core/+bug/1403955/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1403955] Re: DHCP's Option interface-mtu 9000 is being ignored on bridge interface br0
** Changed in: juju-core
Status: New = Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1403955
Title:
DHCP's Option interface-mtu 9000 is being ignored on bridge
interface br0
Status in juju-core:
Invalid
Status in isc-dhcp package in Ubuntu:
Confirmed
Bug description:
In an env with jumbo frames enabled, and using MAAS as DHCP server,
the client receives the following IPv4 lease:
$ cat /var/lib/dhcp/dhclient.br0.leases
lease {
interface br0;
fixed-address 10.230.20.26;
filename pxelinux.0;
option subnet-mask 255.255.248.0;
option dhcp-lease-time 43200;
option routers 10.230.16.1;
option dhcp-message-type 5;
option dhcp-server-identifier 10.230.20.1;
option domain-name-servers 10.230.20.1;
option interface-mtu 9000;
option broadcast-address 10.230.23.255;
option domain-name ctsstack.qa.1ss;
renew 3 2014/12/17 16:48:15;
rebind 3 2014/12/17 21:52:09;
expire 3 2014/12/17 23:22:09;
}
The interfaces show the following config after boot:
$ ifconfig br0
br0 Link encap:Ethernet HWaddr a0:d3:c1:01:9d:58
inet addr:10.230.20.26 Bcast:10.230.23.255 Mask:255.255.248.0
inet6 addr: fe80::a2d3:c1ff:fe01:9d58/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:530530 errors:0 dropped:0 overruns:0 frame:0
TX packets:1591569 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:68713489 (68.7 MB) TX bytes:213710979 (213.7 MB)
$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr a0:d3:c1:01:9d:58
inet6 addr: fe80::a2d3:c1ff:fe01:9d58/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10539274 errors:0 dropped:3394 overruns:0 frame:454
TX packets:2627412 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2320560616 (2.3 GB) TX bytes:3562885157 (3.5 GB)
Interrupt:32
option interface-mtu 9000; from the lease file is being ignored by br0.
Could it be related to eth0 MTU size? If that's the case, shouldn't both
interfaces be updated?
Other info:
$ brctl show br0
bridge name bridge id STP enabled interfaces
br0 8000.a0d3c1019d58 no eth0
$ cat /etc/network/eth0.config
iface eth0 inet manual
auto br0
iface br0 inet dhcp
bridge_ports eth0
To manage notifications about this bug go to:
https://bugs.launchpad.net/juju-core/+bug/1403955/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1403955] Re: DHCP's Option interface-mtu 9000 is being ignored on bridge interface br0
From James's duplicate bug:
In our MAAS based openstack deployment, we provide MTU via DHCP to all
servers to enable jumbo frames.
This works fine until juju creates the bridge devices for LXC or KVM
containers, at which point we reliably lose the MTU 9000 setting on the
bridge, resulting in all sorts of MTU related fun in things like
corosync and percona-cluster which are running under lxc.
We've fixed this by appending an explicit mtu set to the bridge
definition in /etc/network/interfaces:
auto juju-br0
iface juju-br0 inet dhcp
bridge_ports eth0
post-up /sbin/ip link set eth0 mtu 9000
After making this change, we can reliably reboot physical hosts
container lxc containers, an not break our clusters.
The issue is that MTU has to be set on the underlying device, not the
bridge itself - this may actually be something we can fix in the
dhcpclient tools
** Changed in: juju-core
Status: Invalid = Triaged
** Changed in: juju-core
Importance: Undecided = Medium
** Tags added: kvm lxc network
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1403955
Title:
DHCP's Option interface-mtu 9000 is being ignored on bridge
interface br0
Status in juju-core:
Triaged
Status in isc-dhcp package in Ubuntu:
Confirmed
Bug description:
In an env with jumbo frames enabled, and using MAAS as DHCP server,
the client receives the following IPv4 lease:
$ cat /var/lib/dhcp/dhclient.br0.leases
lease {
interface br0;
fixed-address 10.230.20.26;
filename pxelinux.0;
option subnet-mask 255.255.248.0;
option dhcp-lease-time 43200;
option routers 10.230.16.1;
option dhcp-message-type 5;
option dhcp-server-identifier 10.230.20.1;
option domain-name-servers 10.230.20.1;
option interface-mtu 9000;
option broadcast-address 10.230.23.255;
option domain-name ctsstack.qa.1ss;
renew 3 2014/12/17 16:48:15;
rebind 3 2014/12/17 21:52:09;
expire 3 2014/12/17 23:22:09;
}
The interfaces show the following config after boot:
$ ifconfig br0
br0 Link encap:Ethernet HWaddr a0:d3:c1:01:9d:58
inet addr:10.230.20.26 Bcast:10.230.23.255 Mask:255.255.248.0
inet6 addr: fe80::a2d3:c1ff:fe01:9d58/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:530530 errors:0 dropped:0 overruns:0 frame:0
TX packets:1591569 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:68713489 (68.7 MB) TX bytes:213710979 (213.7 MB)
$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr a0:d3:c1:01:9d:58
inet6 addr: fe80::a2d3:c1ff:fe01:9d58/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10539274 errors:0 dropped:3394 overruns:0 frame:454
TX packets:2627412 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2320560616 (2.3 GB) TX bytes:3562885157 (3.5 GB)
Interrupt:32
option interface-mtu 9000; from the lease file is being ignored by br0.
Could it be related to eth0 MTU size? If that's the case, shouldn't both
interfaces be updated?
Other info:
$ brctl show br0
bridge name bridge id STP enabled interfaces
br0 8000.a0d3c1019d58 no eth0
$ cat /etc/network/eth0.config
iface eth0 inet manual
auto br0
iface br0 inet dhcp
bridge_ports eth0
To manage notifications about this bug go to:
https://bugs.launchpad.net/juju-core/+bug/1403955/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1355813] Re: Interface MTU management across MAAS/juju
** Changed in: juju-core Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1355813 Title: Interface MTU management across MAAS/juju Status in juju-core: Fix Released Status in MAAS: New Status in juju-core package in Ubuntu: Triaged Status in lxc package in Ubuntu: Invalid Bug description: Context: juju + MAAS deployed OpenStack environment, misc services deployed under LXC on the bootstrap node, interfaces configured for jumbo frames - note that I had to manually set the LXC container interfaces to mtu 9000 before the bridge would do the same. Action: Reboot one of the containers; MTU on br0 resets from 9000 - 1500. This feels like more of a 'we need a better way to orchestrate MTU configuration across different services' so raising tasks for MAAS and Juju as well. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: lxc 1.0.5-0ubuntu0.1 ProcVersionSignature: User Name 3.13.0-24.47-generic 3.13.9 Uname: Linux 3.13.0-24-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.3 Architecture: amd64 Date: Tue Aug 12 13:26:00 2014 KernLog: SourcePackage: lxc UpgradeStatus: No upgrade log present (probably fresh install) defaults.conf: lxc.network.type = veth lxc.network.link = lxcbr0 lxc.network.flags = up lxc.network.hwaddr = 00:16:3e:xx:xx:xx lxcsyslog: To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1355813/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1402005] Re: agent-state-info: 'error executing lxc-start: command get_cgroup failed to receive response'
** Changed in: juju-core Status: Triaged = Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1402005 Title: agent-state-info: 'error executing lxc-start: command get_cgroup failed to receive response' Status in juju-core: Invalid Status in lxc package in Ubuntu: Incomplete Bug description: We are seeing a few deploys in our automated charm testing fail due to not being able to execute lxc-start. The error we are seeing is: 1: agent-state-info: 'error executing lxc-start: command get_cgroup failed to receive response' instance-id: pending series: precise ref: http://reports.vapour.ws/charm-tests/charm-bundle-test-10698-results/charm/charm-testing-lxc/2 Tim V. has done some initial research on it: https://github.com/lxc/lxc/issues/189 which lead to https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1296459 The fix there was to have 2.8.95~2430-0ubuntu3 installed. Our charm testing infrastructure is running 2.8.95~2430-0ubuntu5. Any help on determining why lxc-start is failing here would be much appreciated. -thanks, Antonio To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1402005/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1402763] Re: Multicast traffic not propating correctly over linux bridge
** Tags added: lxc network ** Changed in: juju-core Status: New = Triaged ** Changed in: juju-core Importance: Undecided = Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1402763 Title: Multicast traffic not propating correctly over linux bridge Status in juju-core: Triaged Status in linux package in Ubuntu: Confirmed Status in lxc package in Ubuntu: Confirmed Bug description: There's a lot of supposition in the title of this bug but its currently my best guess. In this deployment, I have a number of services running in LXC containers across multiple physical hosts; each service is clustered across three units, all on separate physical hosts, using corosync and pacemaker; when using multicast to support cluster communication, I occasionally see a container drop out of the cluster and use its isolation response (to shutdown all managed services); when using unicast I've not yet see this same problem. LXC containers are bridged to the main physical network using a linux bridge: eth0 - juju-br0 - vethXXX - | vethXXX | All MTU's are standard (1500). ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: lxc 1.0.6-0ubuntu0.1 ProcVersionSignature: User Name 3.13.0-40.69-generic 3.13.11.10 Uname: Linux 3.13.0-40-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.6 Architecture: amd64 Date: Mon Dec 15 17:20:08 2014 ProcEnviron: TERM=screen-bce PATH=(custom, no user) XDG_RUNTIME_DIR=set LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: lxc UpgradeStatus: No upgrade log present (probably fresh install) defaults.conf: lxc.network.type = veth lxc.network.link = lxcbr0 lxc.network.flags = up lxc.network.hwaddr = 00:16:3e:xx:xx:xx --- AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Dec 17 10:16 seq crw-rw 1 root audio 116, 33 Dec 17 10:16 timer AplayDevices: Error: [Errno 2] No such file or directory ApportVersion: 2.14.1-0ubuntu3.6 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: DistroRelease: Ubuntu 14.04 IwConfig: Error: [Errno 2] No such file or directory MachineType: Dell Inc. PowerEdge R610 Package: lxc 1.0.6-0ubuntu0.1 PackageArchitecture: amd64 PciMultimedia: ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.13.0-43-generic root=UUID=5a86874d-8bbd-4e7a-b73e-17c914de390b ro ProcEnviron: TERM=screen-bce PATH=(custom, no user) XDG_RUNTIME_DIR=set LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 VESA VGA ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-43-generic root=UUID=5a86874d-8bbd-4e7a-b73e-17c914de390b ro ProcVersionSignature: User Name 3.13.0-43.72-generic 3.13.11.11 RfKill: Error: [Errno 2] No such file or directory Tags: trusty uec-images trusty uec-images apparmor Uname: Linux 3.13.0-43-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm audio cdrom dialout dip floppy libvirtd netdev plugdev sudo video _MarkForUpload: True defaults.conf: lxc.network.type = veth lxc.network.link = lxcbr0 lxc.network.flags = up lxc.network.hwaddr = 00:16:3e:xx:xx:xx dmi.bios.date: 08/18/2011 dmi.bios.vendor: Dell Inc. dmi.bios.version: 6.0.7 dmi.board.name: 0F0XJ6 dmi.board.vendor: Dell Inc. dmi.board.version: A11 dmi.chassis.type: 23 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr6.0.7:bd08/18/2011:svnDellInc.:pnPowerEdgeR610:pvr:rvnDellInc.:rn0F0XJ6:rvrA11:cvnDellInc.:ct23:cvr: dmi.product.name: PowerEdge R610 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1402763/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1402005] Re: agent-state-info: 'error executing lxc-start: command get_cgroup failed to receive response'
lxc*1.0.3 looks odd. That is one version I don't expect to see. trusty has 1.0.6 which is what I think the host is and should be using. a precise host has 1.0.4 found in the cloud tools archive http://ubuntu-cloud.archive.canonical.com/ubuntu/pool/main/l/lxc/ juju stable ppa provides 1.0.0-alpha1, a copy of what was formerly in clout-tools. Does the host need to be upgraded or if precise, use the correct archive? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1402005 Title: agent-state-info: 'error executing lxc-start: command get_cgroup failed to receive response' Status in juju-core: New Status in lxc package in Ubuntu: Incomplete Bug description: We are seeing a few deploys in our automated charm testing fail due to not being able to execute lxc-start. The error we are seeing is: 1: agent-state-info: 'error executing lxc-start: command get_cgroup failed to receive response' instance-id: pending series: precise ref: http://reports.vapour.ws/charm-tests/charm-bundle-test-10698-results/charm/charm-testing-lxc/2 Tim V. has done some initial research on it: https://github.com/lxc/lxc/issues/189 which lead to https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1296459 The fix there was to have 2.8.95~2430-0ubuntu3 installed. Our charm testing infrastructure is running 2.8.95~2430-0ubuntu5. Any help on determining why lxc-start is failing here would be much appreciated. -thanks, Antonio To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1402005/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1402005] Re: agent-state-info: 'error executing lxc-start: command get_cgroup failed to receive response'
The host machine is trusty and was missing updated. We have updated the lxc and other packages. We will watch the processes to see if the issue is resolved or still exists. ** Changed in: juju-core Status: New = Triaged ** Changed in: juju-core Importance: Undecided = High ** Tags added: lxc packaging -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1402005 Title: agent-state-info: 'error executing lxc-start: command get_cgroup failed to receive response' Status in juju-core: Triaged Status in lxc package in Ubuntu: Incomplete Bug description: We are seeing a few deploys in our automated charm testing fail due to not being able to execute lxc-start. The error we are seeing is: 1: agent-state-info: 'error executing lxc-start: command get_cgroup failed to receive response' instance-id: pending series: precise ref: http://reports.vapour.ws/charm-tests/charm-bundle-test-10698-results/charm/charm-testing-lxc/2 Tim V. has done some initial research on it: https://github.com/lxc/lxc/issues/189 which lead to https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1296459 The fix there was to have 2.8.95~2430-0ubuntu3 installed. Our charm testing infrastructure is running 2.8.95~2430-0ubuntu5. Any help on determining why lxc-start is failing here would be much appreciated. -thanks, Antonio To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1402005/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1355813] Re: LXC containers reset bridge MTU on start/restart
** Tags added: cts-cloud-review ** Tags added: add-unit ** Changed in: juju-core Status: New = Triaged ** Changed in: juju-core Importance: Undecided = Medium ** Tags added: placement ** Tags added: network ** Changed in: juju-core Milestone: None = 1.22 ** Changed in: juju-core Importance: Medium = High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1355813 Title: LXC containers reset bridge MTU on start/restart Status in juju-core: Triaged Status in MAAS: Incomplete Status in “lxc” package in Ubuntu: New Bug description: Context: juju + MAAS deployed OpenStack environment, misc services deployed under LXC on the bootstrap node, interfaces configured for jumbo frames - note that I had to manually set the LXC container interfaces to mtu 9000 before the bridge would do the same. Action: Reboot one of the containers; MTU on br0 resets from 9000 - 1500. This feels like more of a 'we need a better way to orchestrate MTU configuration across different services' so raising tasks for MAAS and Juju as well. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: lxc 1.0.5-0ubuntu0.1 ProcVersionSignature: User Name 3.13.0-24.47-generic 3.13.9 Uname: Linux 3.13.0-24-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.3 Architecture: amd64 Date: Tue Aug 12 13:26:00 2014 KernLog: SourcePackage: lxc UpgradeStatus: No upgrade log present (probably fresh install) defaults.conf: lxc.network.type = veth lxc.network.link = lxcbr0 lxc.network.flags = up lxc.network.hwaddr = 00:16:3e:xx:xx:xx lxcsyslog: To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1355813/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1307215] Re: destroy-environment fails to clear lxc containers
** Changed in: juju-core Status: Triaged = Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1307215 Title: destroy-environment fails to clear lxc containers Status in juju-core: Invalid Status in “lxc” package in Ubuntu: Fix Released Bug description: Running destroy-environment with --force happily cleans up evan-local- machine-1, but fails to remove 2 or 3. I think this is what led to bug 1303778 for me. % juju destroy-environment local --force WARNING! this command will destroy the local environment (type: local) This includes all machines, services, data and other resources. Continue [y/N]? y [sudo] password for evan: ERROR failed to destroy lxc container: error executing lxc-destroy: lxc_container: Error destroying rootfs for evan-local-machine-2; Destroying evan-local-machine-2 failed ERROR error executing lxc-destroy: lxc_container: Error destroying rootfs for evan-local-machine-2; Destroying evan-local-machine-2 failed ERROR exit status 1 % sudo lxc-ls -f NAME STATEIPV4 IPV6 AUTOSTART - evan-local-machine-2 STOPPED - - YES evan-local-machine-3 STOPPED - - YES juju-precise-template STOPPED - - NO % juju destroy-environment local --force WARNING! this command will destroy the local environment (type: local) This includes all machines, services, data and other resources. Continue [y/N]? y ERROR failed to destroy lxc container: error executing lxc-destroy: lxc_container: Error destroying rootfs for evan-local-machine-3; Destroying evan-local-machine-3 failed ERROR error executing lxc-destroy: lxc_container: Error destroying rootfs for evan-local-machine-3; Destroying evan-local-machine-3 failed ERROR exit status 1 % sudo lxc-ls -f NAME STATEIPV4 IPV6 AUTOSTART - evan-local-machine-2 STOPPED - - YES evan-local-machine-3 STOPPED - - YES juju-precise-template STOPPED - - NO % juju destroy-environment local --force WARNING! this command will destroy the local environment (type: local) This includes all machines, services, data and other resources. Continue [y/N]? y % sudo lxc-ls -f NAME STATEIPV4 IPV6 AUTOSTART - evan-local-machine-2 STOPPED - - YES evan-local-machine-3 STOPPED - - YES juju-precise-template STOPPED - - NO To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1307215/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1355813] Re: LXC containers reset bridge MTU on start/restart
** Changed in: juju-core Status: New = Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1355813 Title: LXC containers reset bridge MTU on start/restart Status in juju-core: Incomplete Status in MAAS: New Status in “lxc” package in Ubuntu: New Bug description: Context: juju + MAAS deployed OpenStack environment, misc services deployed under LXC on the bootstrap node, interfaces configured for jumbo frames - note that I had to manually set the LXC container interfaces to mtu 9000 before the bridge would do the same. Action: Reboot one of the containers; MTU on br0 resets from 9000 - 1500. This feels like more of a 'we need a better way to orchestrate MTU configuration across different services' so raising tasks for MAAS and Juju as well. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: lxc 1.0.5-0ubuntu0.1 ProcVersionSignature: User Name 3.13.0-24.47-generic 3.13.9 Uname: Linux 3.13.0-24-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.3 Architecture: amd64 Date: Tue Aug 12 13:26:00 2014 KernLog: SourcePackage: lxc UpgradeStatus: No upgrade log present (probably fresh install) defaults.conf: lxc.network.type = veth lxc.network.link = lxcbr0 lxc.network.flags = up lxc.network.hwaddr = 00:16:3e:xx:xx:xx lxcsyslog: To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1355813/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1307215] Re: destroy-environment fails to clear lxc containers
** Tags added: ubuntu-engineering ** Changed in: juju-core Importance: Medium = High ** Changed in: juju-core Milestone: None = next-stable -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1307215 Title: destroy-environment fails to clear lxc containers Status in juju-core: Triaged Status in “lxc” package in Ubuntu: Triaged Bug description: Running destroy-environment with --force happily cleans up evan-local- machine-1, but fails to remove 2 or 3. I think this is what led to bug 1303778 for me. % juju destroy-environment local --force WARNING! this command will destroy the local environment (type: local) This includes all machines, services, data and other resources. Continue [y/N]? y [sudo] password for evan: ERROR failed to destroy lxc container: error executing lxc-destroy: lxc_container: Error destroying rootfs for evan-local-machine-2; Destroying evan-local-machine-2 failed ERROR error executing lxc-destroy: lxc_container: Error destroying rootfs for evan-local-machine-2; Destroying evan-local-machine-2 failed ERROR exit status 1 % sudo lxc-ls -f NAME STATEIPV4 IPV6 AUTOSTART - evan-local-machine-2 STOPPED - - YES evan-local-machine-3 STOPPED - - YES juju-precise-template STOPPED - - NO % juju destroy-environment local --force WARNING! this command will destroy the local environment (type: local) This includes all machines, services, data and other resources. Continue [y/N]? y ERROR failed to destroy lxc container: error executing lxc-destroy: lxc_container: Error destroying rootfs for evan-local-machine-3; Destroying evan-local-machine-3 failed ERROR error executing lxc-destroy: lxc_container: Error destroying rootfs for evan-local-machine-3; Destroying evan-local-machine-3 failed ERROR exit status 1 % sudo lxc-ls -f NAME STATEIPV4 IPV6 AUTOSTART - evan-local-machine-2 STOPPED - - YES evan-local-machine-3 STOPPED - - YES juju-precise-template STOPPED - - NO % juju destroy-environment local --force WARNING! this command will destroy the local environment (type: local) This includes all machines, services, data and other resources. Continue [y/N]? y % sudo lxc-ls -f NAME STATEIPV4 IPV6 AUTOSTART - evan-local-machine-2 STOPPED - - YES evan-local-machine-3 STOPPED - - YES juju-precise-template STOPPED - - NO To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1307215/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1307215] Re: destroy-environment fails to clear lxc containers
** Changed in: juju-core Status: New = Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1307215 Title: destroy-environment fails to clear lxc containers Status in juju-core: Triaged Status in “lxc” package in Ubuntu: New Bug description: Running destroy-environment with --force happily cleans up evan-local- machine-1, but fails to remove 2 or 3. I think this is what led to bug 1303778 for me. % juju destroy-environment local --force WARNING! this command will destroy the local environment (type: local) This includes all machines, services, data and other resources. Continue [y/N]? y [sudo] password for evan: ERROR failed to destroy lxc container: error executing lxc-destroy: lxc_container: Error destroying rootfs for evan-local-machine-2; Destroying evan-local-machine-2 failed ERROR error executing lxc-destroy: lxc_container: Error destroying rootfs for evan-local-machine-2; Destroying evan-local-machine-2 failed ERROR exit status 1 % sudo lxc-ls -f NAME STATEIPV4 IPV6 AUTOSTART - evan-local-machine-2 STOPPED - - YES evan-local-machine-3 STOPPED - - YES juju-precise-template STOPPED - - NO % juju destroy-environment local --force WARNING! this command will destroy the local environment (type: local) This includes all machines, services, data and other resources. Continue [y/N]? y ERROR failed to destroy lxc container: error executing lxc-destroy: lxc_container: Error destroying rootfs for evan-local-machine-3; Destroying evan-local-machine-3 failed ERROR error executing lxc-destroy: lxc_container: Error destroying rootfs for evan-local-machine-3; Destroying evan-local-machine-3 failed ERROR exit status 1 % sudo lxc-ls -f NAME STATEIPV4 IPV6 AUTOSTART - evan-local-machine-2 STOPPED - - YES evan-local-machine-3 STOPPED - - YES juju-precise-template STOPPED - - NO % juju destroy-environment local --force WARNING! this command will destroy the local environment (type: local) This includes all machines, services, data and other resources. Continue [y/N]? y % sudo lxc-ls -f NAME STATEIPV4 IPV6 AUTOSTART - evan-local-machine-2 STOPPED - - YES evan-local-machine-3 STOPPED - - YES juju-precise-template STOPPED - - NO To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1307215/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
