[Touch-packages] [Bug 1668123] Re: lxc fails to start with cgroup error
** Changed in: systemd (Ubuntu) Status: Incomplete => 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/1668123 Title: lxc fails to start with cgroup error Status in systemd package in Ubuntu: New Bug description: After rebooting a KVM instance hosting LXCs, we get the following error: $ sudo lxc-ls --fancy lxc: cgmanager.c: lxc_cgmanager_escape: 331 call to cgmanager_move_pid_abs_sync(name=dsystemd) failed: invalid request and the LXCs won't start up. In the error logs it showed: lxc-start 1487906073.534 ERRORlxc_cgfs - cgfs.c:lxc_cgroupfs_create:873 - Could not find writable mount point for cgroup hierarchy 11 while trying to create cgroup. The only way I could get the lxcs started was to stop and start cgmanager, just a simple restart wasn't sufficient. Please let me know if you need any further information. $ lsb_release -a Description: Ubuntu 14.04.5 LTS Release: 14.04 $ dpkg-query -W systemd systemd 204-5ubuntu20.24 $ dpkg-query -W cgmanager cgmanager 0.24-0ubuntu7.5 $ dpkg-query -W lxc lxc 1.0.9-0ubuntu2 $ uname -a Linux infra 3.13.0-110-generic #157-Ubuntu SMP Mon Feb 20 11:54:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1668123/+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 1668123] Re: lxc fails to start with cgroup error
I've had this occur on another system, and this time I could debug it a little more freely. This is an interesting output: # dpkg --purge --simulate systemd dpkg: dependency problems prevent removal of systemd: snapd depends on systemd (>= 204-5ubuntu20.20); however: Package systemd is to be removed. dpkg: error processing package systemd (--purge): dependency problems - not removing Errors were encountered while processing: systemd Now, why snapd was installed I'm not sure, but I guess that's what installed systemd, since the snapd package depends on systemd. -- 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/1668123 Title: lxc fails to start with cgroup error Status in systemd package in Ubuntu: New Bug description: After rebooting a KVM instance hosting LXCs, we get the following error: $ sudo lxc-ls --fancy lxc: cgmanager.c: lxc_cgmanager_escape: 331 call to cgmanager_move_pid_abs_sync(name=dsystemd) failed: invalid request and the LXCs won't start up. In the error logs it showed: lxc-start 1487906073.534 ERRORlxc_cgfs - cgfs.c:lxc_cgroupfs_create:873 - Could not find writable mount point for cgroup hierarchy 11 while trying to create cgroup. The only way I could get the lxcs started was to stop and start cgmanager, just a simple restart wasn't sufficient. Please let me know if you need any further information. $ lsb_release -a Description: Ubuntu 14.04.5 LTS Release: 14.04 $ dpkg-query -W systemd systemd 204-5ubuntu20.24 $ dpkg-query -W cgmanager cgmanager 0.24-0ubuntu7.5 $ dpkg-query -W lxc lxc 1.0.9-0ubuntu2 $ uname -a Linux infra 3.13.0-110-generic #157-Ubuntu SMP Mon Feb 20 11:54:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1668123/+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 1668123] Re: lxc fails to start with cgroup error
> Sidenote) the 18GB of /var/lib/juju/db (with backups, of backups, of backups) > was not helpful, I'll need to talk to sosreport people about that. This is > what made the report so huge. I did notice that, but I figured getting you all of the data was better than fiddling around trying to not include that part, and maybe missing bits. It'd be nice to have better control over it so we don't have to throw the juju state db around if we don't need to. > 1) It appears that deputy systemd was installed on the machine and > subsequently upgraded: > 2017-02-12 01:30:24 upgrade systemd:amd64 204-5ubuntu20.22 204-5ubuntu20.24 > However, there are no logs available as to what/who/why 20.22 deputy systemd > was installed. Interesting. I don't really know why it would have been installed. > 2) Have you tried to use snapd on trusty on that host? Has anything else > tried to do that? (e.g. juju manual provider or some such?!) No, I don't believe anyone has, I don't see any evidence of that. > 3) To recover the system, you should $ apt remove systemd; and reboot. > However that is the workaround Ok, I'll organise removing the package and rebooting it. > 4) Is this nested lxc? or errors inside the instances? > E.g. from logs I see failures to start lxc instances, but I don't see logs > for failing to start instances for some reason. This is LXCs on a KVM. The errors are in /var/log/lxc, its odd that the sosreport didn't include it. > 5) Why was lxc downgraded/upgraded/downgraded multiple times? We were trying to work out if LP#1656280 was related somehow, the errors were occuring before we did that. > 6) Are the error messages from this machine? Whilst I do see that systemd is > installed, and dsystemd cgroup is mounted, I am failing to find the logs for > any lxc failures related to starting them. The errors are in /var/log/lxc - see the next reply. > Is there /var/log/lxc or some such that you could share privately? for > some reason it was not part of the sosreport. I've uploaded it to https://private- fileshare.canonical.com/~bradm/lp1668123/lp1668123-var-log-lxc.tar.gz > cgmanager should not be interracting with dsystemd. > systemd should not be present on this system (as hwe kernel is not in use, > nor is snapd). > lxc should work irrespective of dsystemd. Its odd that stopping and starting cgmanager would let LXC work then. > I will setup trusty, with GA kernel, lxc1, deploy any charm (e.g. ubuntu), > and install deputy systemd to try to reproduce this test case. > I wonder if upstart systemd job should be neutered, unless snapd is present, > and we are booted with hwe kernel. It does sound like a good idea if we're going to have failures like what we saw. -- 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/1668123 Title: lxc fails to start with cgroup error Status in systemd package in Ubuntu: Incomplete Bug description: After rebooting a KVM instance hosting LXCs, we get the following error: $ sudo lxc-ls --fancy lxc: cgmanager.c: lxc_cgmanager_escape: 331 call to cgmanager_move_pid_abs_sync(name=dsystemd) failed: invalid request and the LXCs won't start up. In the error logs it showed: lxc-start 1487906073.534 ERRORlxc_cgfs - cgfs.c:lxc_cgroupfs_create:873 - Could not find writable mount point for cgroup hierarchy 11 while trying to create cgroup. The only way I could get the lxcs started was to stop and start cgmanager, just a simple restart wasn't sufficient. Please let me know if you need any further information. $ lsb_release -a Description: Ubuntu 14.04.5 LTS Release: 14.04 $ dpkg-query -W systemd systemd 204-5ubuntu20.24 $ dpkg-query -W cgmanager cgmanager 0.24-0ubuntu7.5 $ dpkg-query -W lxc lxc 1.0.9-0ubuntu2 $ uname -a Linux infra 3.13.0-110-generic #157-Ubuntu SMP Mon Feb 20 11:54:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1668123/+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 1668123] Re: lxc fails to start with cgroup error
It's uploading slowly to https://private- fileshare.canonical.com/~bradm/lp1668123/, once you see the .md5 file in place and the sosreport is 7.7G, it'll be done. -- 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/1668123 Title: lxc fails to start with cgroup error Status in systemd package in Ubuntu: Confirmed Bug description: After rebooting a KVM instance hosting LXCs, we get the following error: $ sudo lxc-ls --fancy lxc: cgmanager.c: lxc_cgmanager_escape: 331 call to cgmanager_move_pid_abs_sync(name=dsystemd) failed: invalid request and the LXCs won't start up. In the error logs it showed: lxc-start 1487906073.534 ERRORlxc_cgfs - cgfs.c:lxc_cgroupfs_create:873 - Could not find writable mount point for cgroup hierarchy 11 while trying to create cgroup. The only way I could get the lxcs started was to stop and start cgmanager, just a simple restart wasn't sufficient. Please let me know if you need any further information. $ lsb_release -a Description: Ubuntu 14.04.5 LTS Release: 14.04 $ dpkg-query -W systemd systemd 204-5ubuntu20.24 $ dpkg-query -W cgmanager cgmanager 0.24-0ubuntu7.5 $ dpkg-query -W lxc lxc 1.0.9-0ubuntu2 $ uname -a Linux infra 3.13.0-110-generic #157-Ubuntu SMP Mon Feb 20 11:54:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1668123/+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 1668123] Re: lxc fails to start with cgroup error
I've generated a sosreport, but its 7.7G. How would you like me to get this to you? The interesting part is that all this was deployed via juju, so I don't know how we got into this state. It also appears to be the only node in this state, so its a bit confusing as to how it got to be this way. Is there anything I can check configuration wise to see why its using deputy systemd? Its certainly not something we've explicitly picked as far as I know. -- 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/1668123 Title: lxc fails to start with cgroup error Status in systemd package in Ubuntu: Confirmed Bug description: After rebooting a KVM instance hosting LXCs, we get the following error: $ sudo lxc-ls --fancy lxc: cgmanager.c: lxc_cgmanager_escape: 331 call to cgmanager_move_pid_abs_sync(name=dsystemd) failed: invalid request and the LXCs won't start up. In the error logs it showed: lxc-start 1487906073.534 ERRORlxc_cgfs - cgfs.c:lxc_cgroupfs_create:873 - Could not find writable mount point for cgroup hierarchy 11 while trying to create cgroup. The only way I could get the lxcs started was to stop and start cgmanager, just a simple restart wasn't sufficient. Please let me know if you need any further information. $ lsb_release -a Description: Ubuntu 14.04.5 LTS Release: 14.04 $ dpkg-query -W systemd systemd 204-5ubuntu20.24 $ dpkg-query -W cgmanager cgmanager 0.24-0ubuntu7.5 $ dpkg-query -W lxc lxc 1.0.9-0ubuntu2 $ uname -a Linux infra 3.13.0-110-generic #157-Ubuntu SMP Mon Feb 20 11:54:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1668123/+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 1668123] [NEW] lxc fails to start with cgroup error
Public bug reported: After rebooting a KVM instance hosting LXCs, we get the following error: $ sudo lxc-ls --fancy lxc: cgmanager.c: lxc_cgmanager_escape: 331 call to cgmanager_move_pid_abs_sync(name=dsystemd) failed: invalid request and the LXCs won't start up. In the error logs it showed: lxc-start 1487906073.534 ERRORlxc_cgfs - cgfs.c:lxc_cgroupfs_create:873 - Could not find writable mount point for cgroup hierarchy 11 while trying to create cgroup. The only way I could get the lxcs started was to stop and start cgmanager, just a simple restart wasn't sufficient. Please let me know if you need any further information. $ lsb_release -a Description:Ubuntu 14.04.5 LTS Release:14.04 $ dpkg-query -W systemd systemd 204-5ubuntu20.24 $ dpkg-query -W cgmanager cgmanager 0.24-0ubuntu7.5 $ dpkg-query -W lxc lxc 1.0.9-0ubuntu2 $ uname -a Linux infra 3.13.0-110-generic #157-Ubuntu SMP Mon Feb 20 11:54:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: canonical-bootstack -- 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/1668123 Title: lxc fails to start with cgroup error Status in systemd package in Ubuntu: New Bug description: After rebooting a KVM instance hosting LXCs, we get the following error: $ sudo lxc-ls --fancy lxc: cgmanager.c: lxc_cgmanager_escape: 331 call to cgmanager_move_pid_abs_sync(name=dsystemd) failed: invalid request and the LXCs won't start up. In the error logs it showed: lxc-start 1487906073.534 ERRORlxc_cgfs - cgfs.c:lxc_cgroupfs_create:873 - Could not find writable mount point for cgroup hierarchy 11 while trying to create cgroup. The only way I could get the lxcs started was to stop and start cgmanager, just a simple restart wasn't sufficient. Please let me know if you need any further information. $ lsb_release -a Description: Ubuntu 14.04.5 LTS Release: 14.04 $ dpkg-query -W systemd systemd 204-5ubuntu20.24 $ dpkg-query -W cgmanager cgmanager 0.24-0ubuntu7.5 $ dpkg-query -W lxc lxc 1.0.9-0ubuntu2 $ uname -a Linux infra 3.13.0-110-generic #157-Ubuntu SMP Mon Feb 20 11:54:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1668123/+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 1578080] Re: percona cluster hits resource limits in HA Openstack cloud with xenial
I've upgraded systemd across my cluster to 229-4ubuntu6, removed all my custom tweaks to systemd settings, reloaded the daemon and both rabbitmq and mysql appear to be working fine on my openstack cluster. I'll be throwing a bit more load at it, but usually by this point mysql has fallen over, so I'd say this is a success. ** Tags removed: verification-needed ** Tags added: verification-done -- 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/1578080 Title: percona cluster hits resource limits in HA Openstack cloud with xenial Status in percona-xtradb-cluster-5.6 package in Ubuntu: Won't Fix Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Committed Status in percona-cluster package in Juju Charms Collection: Won't Fix Status in systemd package in Debian: Confirmed Bug description: I'm trying to deploy Mitaka Openstack using the 16.04 charms on Xenial using Juju 1.25.5 and MAAS 1.9.2, with as many components of Openstack being HA as possible. When deployed, after running for a while mysql (which is a 3 node cluster) starts refusing connections, and erroring: 2016-05-03 01:25:28 13795 [ERROR] Error log throttle: 50 'Can't create thread to handle new connection' error(s) suppressed When I look at systemd-cgtop, I can see it maxing out at 512 connections. To get it going again I do a: $ sudo systemctl edit mysql and set: TasksMax=infinity Sometimes I even need to edit /etc/systemd/system.conf and bump DefaultTasksMax to 1024 or higher, depending on long its been left running. I've noticed that dropping worker-multiplier setting on nova-cloud- controller, neutron-api etc all help to reduce the load, but I still need to bump it up. Please let me know if you need any more information. SRU INFORMATION --- Impact: Introducing a default #thread limit of 512 broke an unknown set of services which regularly run many threads. Fix: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=fe4d9d3ba0 (essentially, revert the upstream commit that enabled it) Regression potential: Very low -- this just restores the pre-228 behaviour and does not impose any new restriction. Test case: - Pick some unit like cron.service or mysql.service that does not specify an explicit TaskMax= limit. - Check its TaskMax: systemctl show -p TasksMax cron.service - In current xenial this is "512", after the update it should be a very big number (maxint minus 1, which means "infinity") To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/percona-xtradb-cluster-5.6/+bug/1578080/+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 1515463] Re: Broken juju LXC deployments
This does indeed appear to work correctly, I've deployed a container
using juju:
ubuntu@apollo:~$ dpkg-query -W lxc
lxc 1.0.8-0ubuntu0.3
ubuntu@apollo:~$ sudo lxc-ls --fancy
NAME STATEIPV4IPV6 AUTOSTART
--
juju-machine-0-lxc-0 RUNNING x.y.z.171 - YES
juju-trusty-lxc-template STOPPED - - NO
ubuntu@apollo:~$ sudo lxc-attach -n juju-machine-0-lxc-0
root@juju-machine-0-lxc-0:~#
Thanks!
--
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/1515463
Title:
Broken juju LXC deployments
Status in lxc package in Ubuntu:
Fix Released
Status in lxc source package in Trusty:
Fix Committed
Status in lxc source package in Vivid:
Fix Committed
Status in lxc source package in Wily:
Fix Committed
Status in lxc source package in Xenial:
Fix Released
Bug description:
I've just tried using juju to deploy to a container with trusty-
proposed repo enabled, and I get an error message about 'failed to
retrieve the template to clone'. The underlying error appears to be:
tar --numeric-owner -xpJf
/var/cache/lxc/cloud-trusty/ubuntu-14.04-server-cloudimg-amd64-root.tar.gz;
xz: (stdin): File format not recognized; tar: Child returned status 1; tar:
Error is not recoverable: exiting now;
This seems to be fairly obvious, trying to use xz on a tar.gz file is
never going to work.
The change appears to be from
https://github.com/lxc/lxc/commit/27c278a76931bfc4660caa85d1942ca91c86e0bf,
it assumes everything passed into it will be a .tar.xz file.
This appears to be a conflict between the template expecting a .tar.xz
file, and juju providing it a .tar.gz file. You can see what juju is
providing from:
$ ubuntu-cloudimg-query trusty released amd64 --format %{url}
https://cloud-images.ubuntu.com/server/releases/trusty/release-20151105/ubuntu-14.04-server-cloudimg-amd64.tar.gz
From the juju deployed host:
$ apt-cache policy lxc-templates
lxc-templates:
Installed: 1.0.8-0ubuntu0.1
Candidate: 1.0.8-0ubuntu0.1
Version table:
*** 1.0.8-0ubuntu0.1 0
500 http://archive.ubuntu.com/ubuntu/ trusty-proposed/main amd64
Packages
100 /var/lib/dpkg/status
From the host running juju:
$ apt-cache policy juju-core
juju-core:
Installed: 1.22.8-0ubuntu1~14.04.1
Candidate: 1.25.0-0ubuntu1~14.04.1~juju1
Version table:
1.25.0-0ubuntu1~14.04.1~juju1 0
500 http://ppa.launchpad.net/juju/proposed/ubuntu/ trusty/main amd64
Packages
*** 1.22.8-0ubuntu1~14.04.1 0
400 http://archive.ubuntu.com/ubuntu/ trusty-proposed/universe amd64
Packages
100 /var/lib/dpkg/status
All machine involved are running trusty:
$ lsb_release -rd
Description:Ubuntu 14.04.3 LTS
Release:14.04
Please let me know if you need any more information.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1515463/+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 1515463] Re: Broken juju LXC deployments
FWIW and a totally expected result, I just downgraded the LXC packages
on these hosts and redeployed, and things came up ok.
$ dpkg-query -W lxc
lxc 1.0.7-0ubuntu0.10
I don't think this changes anything, but just putting it here for
completeness.
--
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/1515463
Title:
Broken juju LXC deployments
Status in lxc package in Ubuntu:
New
Bug description:
I've just tried using juju to deploy to a container with trusty-
proposed repo enabled, and I get an error message about 'failed to
retrieve the template to clone'. The underlying error appears to be:
tar --numeric-owner -xpJf
/var/cache/lxc/cloud-trusty/ubuntu-14.04-server-cloudimg-amd64-root.tar.gz;
xz: (stdin): File format not recognized; tar: Child returned status 1; tar:
Error is not recoverable: exiting now;
This seems to be fairly obvious, trying to use xz on a tar.gz file is
never going to work.
The change appears to be from
https://github.com/lxc/lxc/commit/27c278a76931bfc4660caa85d1942ca91c86e0bf,
it assumes everything passed into it will be a .tar.xz file.
This appears to be a conflict between the template expecting a .tar.xz
file, and juju providing it a .tar.gz file. You can see what juju is
providing from:
$ ubuntu-cloudimg-query trusty released amd64 --format %{url}
https://cloud-images.ubuntu.com/server/releases/trusty/release-20151105/ubuntu-14.04-server-cloudimg-amd64.tar.gz
From the juju deployed host:
$ apt-cache policy lxc-templates
lxc-templates:
Installed: 1.0.8-0ubuntu0.1
Candidate: 1.0.8-0ubuntu0.1
Version table:
*** 1.0.8-0ubuntu0.1 0
500 http://archive.ubuntu.com/ubuntu/ trusty-proposed/main amd64
Packages
100 /var/lib/dpkg/status
From the host running juju:
$ apt-cache policy juju-core
juju-core:
Installed: 1.22.8-0ubuntu1~14.04.1
Candidate: 1.25.0-0ubuntu1~14.04.1~juju1
Version table:
1.25.0-0ubuntu1~14.04.1~juju1 0
500 http://ppa.launchpad.net/juju/proposed/ubuntu/ trusty/main amd64
Packages
*** 1.22.8-0ubuntu1~14.04.1 0
400 http://archive.ubuntu.com/ubuntu/ trusty-proposed/universe amd64
Packages
100 /var/lib/dpkg/status
All machine involved are running trusty:
$ lsb_release -rd
Description:Ubuntu 14.04.3 LTS
Release:14.04
Please let me know if you need any more information.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1515463/+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 1515463] [NEW] Broken juju LXC deployments
Public bug reported:
I've just tried using juju to deploy to a container with trusty-proposed
repo enabled, and I get an error message about 'failed to retrieve the
template to clone'. The underlying error appears to be:
tar --numeric-owner -xpJf
/var/cache/lxc/cloud-trusty/ubuntu-14.04-server-cloudimg-amd64-root.tar.gz;
xz: (stdin): File format not recognized; tar: Child returned status 1; tar:
Error is not recoverable: exiting now;
This seems to be fairly obvious, trying to use xz on a tar.gz file is
never going to work.
The change appears to be from
https://github.com/lxc/lxc/commit/27c278a76931bfc4660caa85d1942ca91c86e0bf,
it assumes everything passed into it will be a .tar.xz file.
This appears to be a conflict between the template expecting a .tar.xz
file, and juju providing it a .tar.gz file. You can see what juju is
providing from:
$ ubuntu-cloudimg-query trusty released amd64 --format %{url}
https://cloud-images.ubuntu.com/server/releases/trusty/release-20151105/ubuntu-14.04-server-cloudimg-amd64.tar.gz
>From the juju deployed host:
$ apt-cache policy lxc-templates
lxc-templates:
Installed: 1.0.8-0ubuntu0.1
Candidate: 1.0.8-0ubuntu0.1
Version table:
*** 1.0.8-0ubuntu0.1 0
500 http://archive.ubuntu.com/ubuntu/ trusty-proposed/main amd64
Packages
100 /var/lib/dpkg/status
>From the host running juju:
$ apt-cache policy juju-core
juju-core:
Installed: 1.22.8-0ubuntu1~14.04.1
Candidate: 1.25.0-0ubuntu1~14.04.1~juju1
Version table:
1.25.0-0ubuntu1~14.04.1~juju1 0
500 http://ppa.launchpad.net/juju/proposed/ubuntu/ trusty/main amd64
Packages
*** 1.22.8-0ubuntu1~14.04.1 0
400 http://archive.ubuntu.com/ubuntu/ trusty-proposed/universe amd64
Packages
100 /var/lib/dpkg/status
All machine involved are running trusty:
$ lsb_release -rd
Description:Ubuntu 14.04.3 LTS
Release:14.04
Please let me know if you need any more information.
** Affects: lxc (Ubuntu)
Importance: Undecided
Status: New
** Tags: canonical-bootstack
--
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/1515463
Title:
Broken juju LXC deployments
Status in lxc package in Ubuntu:
New
Bug description:
I've just tried using juju to deploy to a container with trusty-
proposed repo enabled, and I get an error message about 'failed to
retrieve the template to clone'. The underlying error appears to be:
tar --numeric-owner -xpJf
/var/cache/lxc/cloud-trusty/ubuntu-14.04-server-cloudimg-amd64-root.tar.gz;
xz: (stdin): File format not recognized; tar: Child returned status 1; tar:
Error is not recoverable: exiting now;
This seems to be fairly obvious, trying to use xz on a tar.gz file is
never going to work.
The change appears to be from
https://github.com/lxc/lxc/commit/27c278a76931bfc4660caa85d1942ca91c86e0bf,
it assumes everything passed into it will be a .tar.xz file.
This appears to be a conflict between the template expecting a .tar.xz
file, and juju providing it a .tar.gz file. You can see what juju is
providing from:
$ ubuntu-cloudimg-query trusty released amd64 --format %{url}
https://cloud-images.ubuntu.com/server/releases/trusty/release-20151105/ubuntu-14.04-server-cloudimg-amd64.tar.gz
From the juju deployed host:
$ apt-cache policy lxc-templates
lxc-templates:
Installed: 1.0.8-0ubuntu0.1
Candidate: 1.0.8-0ubuntu0.1
Version table:
*** 1.0.8-0ubuntu0.1 0
500 http://archive.ubuntu.com/ubuntu/ trusty-proposed/main amd64
Packages
100 /var/lib/dpkg/status
From the host running juju:
$ apt-cache policy juju-core
juju-core:
Installed: 1.22.8-0ubuntu1~14.04.1
Candidate: 1.25.0-0ubuntu1~14.04.1~juju1
Version table:
1.25.0-0ubuntu1~14.04.1~juju1 0
500 http://ppa.launchpad.net/juju/proposed/ubuntu/ trusty/main amd64
Packages
*** 1.22.8-0ubuntu1~14.04.1 0
400 http://archive.ubuntu.com/ubuntu/ trusty-proposed/universe amd64
Packages
100 /var/lib/dpkg/status
All machine involved are running trusty:
$ lsb_release -rd
Description:Ubuntu 14.04.3 LTS
Release:14.04
Please let me know if you need any more information.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1515463/+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 1186662] Re: isc-dhcp-server fails to renew lease file
** Tags added: canonical-bootstack -- 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/1186662 Title: isc-dhcp-server fails to renew lease file Status in isc-dhcp package in Ubuntu: Triaged Status in isc-dhcp source package in Trusty: Confirmed Bug description: After raring upgrade, the dhcp server fails to renew lease file when it tries to (about every hour). The syslog says: dhcpd: Can't create new lease file: Permission denied It looks like a permission problem, because # chown -R dhcpd:dhcpd /var/lib/dhcp the above command temporarily solves the issue, until dhcpd is restarted: at that time, the ownership of the directory and the lease file is set back to root:root. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1186662/+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 1432493] [NEW] ntp dhcp hook doesn't check if ntp.conf has been updated
Public bug reported: /etc/dhcp/dhclient-exit-hooks.d/ntp doesn't check if /etc/ntp.conf has been updated since the last time dhclient ran. A simple addition of a check to see if /etc/ntp.conf is newer than /var/lib/ntp/ntp.conf.dhcp, and if so letting it add the servers would be sufficient. This is occuring on a Trusty host with ntp version 1:4.2.6.p5+dfsg- 3ubuntu2.14.04.2. Please let me know if you need any further information. $ dpkg-query -W ntp ntp 1:4.2.6.p5+dfsg-3ubuntu2.14.04.2 $ lsb_release -d Description:Ubuntu 14.04.2 LTS ** Affects: ntp (Ubuntu) Importance: Undecided Status: New ** Tags: canonical-bootstack ** Tags added: canonical-bootstack -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1432493 Title: ntp dhcp hook doesn't check if ntp.conf has been updated Status in ntp package in Ubuntu: New Bug description: /etc/dhcp/dhclient-exit-hooks.d/ntp doesn't check if /etc/ntp.conf has been updated since the last time dhclient ran. A simple addition of a check to see if /etc/ntp.conf is newer than /var/lib/ntp/ntp.conf.dhcp, and if so letting it add the servers would be sufficient. This is occuring on a Trusty host with ntp version 1:4.2.6.p5+dfsg- 3ubuntu2.14.04.2. Please let me know if you need any further information. $ dpkg-query -W ntp ntp 1:4.2.6.p5+dfsg-3ubuntu2.14.04.2 $ lsb_release -d Description: Ubuntu 14.04.2 LTS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1432493/+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 1421075] [NEW] Typo with dynamically removing port forward in ssh
Public bug reported: When using ssh and managing ssh port forwards with ~C to remove a forward that doesn't exist, the following occurs: user@host:~$ ssh -KD12345 Unkown port forwarding. ie, the mispelling of the work Unknown as 'Unkown'. This occurs at least on a server running on trusty: $ dpkg --list | grep openssh ii openssh-client 1:6.6p1-2ubuntu2 amd64secure shell (SSH) client, for secure access to remote machines ii openssh-server 1:6.6p1-2ubuntu2 amd64secure shell (SSH) server, for secure access from remote machines ii openssh-sftp-server 1:6.6p1-2ubuntu2 amd64secure shell (SSH) sftp server module, for SFTP access from remote machines Please let me know if you need any more information. ** Affects: openssh (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1421075 Title: Typo with dynamically removing port forward in ssh Status in openssh package in Ubuntu: New Bug description: When using ssh and managing ssh port forwards with ~C to remove a forward that doesn't exist, the following occurs: user@host:~$ ssh -KD12345 Unkown port forwarding. ie, the mispelling of the work Unknown as 'Unkown'. This occurs at least on a server running on trusty: $ dpkg --list | grep openssh ii openssh-client 1:6.6p1-2ubuntu2 amd64secure shell (SSH) client, for secure access to remote machines ii openssh-server 1:6.6p1-2ubuntu2 amd64secure shell (SSH) server, for secure access from remote machines ii openssh-sftp-server 1:6.6p1-2ubuntu2 amd64secure shell (SSH) sftp server module, for SFTP access from remote machines Please let me know if you need any more information. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1421075/+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
