Ahm, yes, there's another problem, but completely different one.
The upgrade procedure vom 18.04 to 20.04 converts LXD images from the
old debian based LXD to the snap based LXD and thus from /var/lib/lxd to
/var/snap/lxd/common/lxd and thus out of the encrypted directory.
I'm not sure whether
Well, seems so. I will reliably know it after upgrading, but for the
moment I don't see any obstacle anymore.
Thanks for helping.
Maybe turn this into a documentation / argument naming bug.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
yeah, i agree, the docs could be better here ... the output of "snap
stop --help" and "snap disable --help" do show similar text ...
to see the (en/disabled) state of any snap based services you can use
the "snap services" command ...
does using snap stop solve your issue though ?
--
You
Ah, yes.
When looking for a solution I ran onto some ubuntu answers page which
claimed that snap stop --disable is the same as snap stop + snap
disable.
And the snap manpage I've read is not explicit about the fact that
there's two different sorts of 'disabled', that disabling the snap and
> # snap enable lxd
> lxd enabled
could it be that you disabled the whole snap instead of just the daemon
in the snap (i think then it is indeed expected that the systemd units
go away) ?
you need to use "snap stop --disable lxd" to disable the service, not
"snap disable lxd" which takes the
That's what it looks like here (the 20.04 machine I sent the bug report
from):
# snap start lxd
error: cannot perform the following tasks:
- start of [lxd.activate lxd.daemon] (# systemctl start
snap.lxd.activate.service snap.lxd.daemon.service
Failed to start snap.lxd.activate.service: Unit
note that this is not reproducable on any machine i tried, as described
in:
https://forum.snapcraft.io/t/have-a-snap-be-run-only-when-started-
manually/20493
The mechanism to manually start disabled snap services seems to work
just as it should (and given how many snaps in IoT use such a setup
