© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
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.
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.
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?!)
3) To recover the system, you should $ apt remove systemd; and reboot. However that is the workaround
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.
5) Why was lxc downgraded/
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.
Is there /var/log/lxc or some such that you could share privately? for some reason it was not part of the sosreport.
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.
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.