Disabling autopilot (was: member not found)

Gábor Paller gaborpaller at gmail.com
Wed Nov 4 17:54:24 UTC 2015


I ended up renaming /lib/systemd/system/snappy-autopilot.timer and
/lib/systemd/system/snappy-autopilot.service files. That solved the problem
even though something recreated the symlink under
/etc/systemd/system/multi-user.target.wants but now that symlink is broken.

Booting after these modifications revealed that the autopilot is indeed
activated by some systemd dependency mechanisms.
Excerpt from the boot log:
...
[   13.974436] systemd[1]: Mounted /etc/modprobe.d.
[   13.979589] systemd[1]: Mounted /etc/ufw.
[   13.984010] systemd[1]: Mounted /etc/systemd/system.
[   13.989469] systemd[1]: Mounted /.
[   13.993256] systemd[1]: Mounted /etc/udev/rules.d.
[   13.998550] systemd[1]: Mounted /etc/network/interfaces.d.
[   14.004503] systemd[1]: Mounted /etc/dbus-1/system.d.
[   14.009979] systemd[1]: Mounted /etc/ppp.
[   14.014352] systemd[1]: Mounted /etc/apparmor.d/cache.
[   14.033673] systemd[1]: Cannot add dependency semmi2.tmp to
multi-user.target, ignoring: Invalid argument
[   14.088900] systemd[1]: Cannot add dependency semmi2.tmp to
multi-user.target, ignoring: Invalid argument
[   14.101986] systemd[1]: Cannot add dependency semmi2.tmp to
multi-user.target, ignoring: Invalid argument
[   14.118555] systemd[1]: Cannot add dependency job for unit
sshd-keygen.service, ignoring: Unit sshd-keygen.service failed to load: No
such file or directory.
[   14.133601] systemd[1]: Cannot add dependency job for unit
snappy-autopilot.timer, ignoring: Unit snappy-autopilot.timer failed to
load: No such file or directory.
[   14.149372] systemd[1]: Cannot add dependency job for unit
display-manager.service, ignoring: Unit display-manager.service failed to
load: No such file or directory.
[  OK  ] Reached target Remote File Systems (Pre).
[   14.179336] systemd[1]: Reached target Remote File Systems (Pre).
[   14.185913] systemd[1]: Starting Remote File Systems (Pre).

Note that semmi2.tmp is a dummy file created in
/etc/systemd/system/multi-user.target.wants that I added out of desperation
to figure out whether changes to the file system survive reboot. But
systemd tries to link in even that file. If I understand the error message
related to snappy-autopilot.timer and snappy-autopilot.service, some
systemd units listed those services in their WantedBy section. So far I
haven't found the culprit. But at least the autopilot is gone.

Regards,
Gabor

On Wed, Nov 4, 2015 at 3:44 PM, John Lenton <john.lenton at canonical.com>
wrote:

> On 2 November 2015 at 11:20, Gábor Paller <gaborpaller at gmail.com> wrote:
> > Can this be the BeagleBone's SD card filesystem?
>
> I don't know what is doing it; as far as I can tell, you've modified
> the base system (that's supposed to be readonly), so I have no way to
> guess what's going on. I can't reproduce your issue on a snappy
> ubuntu-core bbb (and as far as I know that what you're seeing doesn't
> happen is covered by our automated integration tests).
>
> If I had to guess I'd say you've somehow changed the order in which
> things happen on boot, or otherwise made it so that the firstboot
> stamp is either not written or written to something ephemeral, and the
> firstboot run is being done every time.
>
> But that's all guesswork on my part.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20151104/08b3cc1d/attachment.html>


More information about the snappy-devel mailing list