<div dir="ltr"><div><div><div><div><div>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.<br><br></div>Booting after these modifications revealed that the autopilot is indeed activated by some systemd dependency mechanisms.<br></div>Excerpt from the boot log:<br>...<br>[   13.974436] systemd[1]: Mounted /etc/modprobe.d.<br>[   13.979589] systemd[1]: Mounted /etc/ufw.<br>[   13.984010] systemd[1]: Mounted /etc/systemd/system.<br>[   13.989469] systemd[1]: Mounted /.<br>[   13.993256] systemd[1]: Mounted /etc/udev/rules.d.<br>[   13.998550] systemd[1]: Mounted /etc/network/interfaces.d.<br>[   14.004503] systemd[1]: Mounted /etc/dbus-1/system.d.<br>[   14.009979] systemd[1]: Mounted /etc/ppp.<br>[   14.014352] systemd[1]: Mounted /etc/apparmor.d/cache.<br>[   14.033673] systemd[1]: Cannot add dependency semmi2.tmp to multi-user.target, ignoring: Invalid argument<br>[   14.088900] systemd[1]: Cannot add dependency semmi2.tmp to multi-user.target, ignoring: Invalid argument<br>[   14.101986] systemd[1]: Cannot add dependency semmi2.tmp to multi-user.target, ignoring: Invalid argument<br>[   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.<br>[   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.<br>[   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.<br>[  OK  ] Reached target Remote File Systems (Pre).<br>[   14.179336] systemd[1]: Reached target Remote File Systems (Pre).<br>[   14.185913] systemd[1]: Starting Remote File Systems (Pre).<br><br></div>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.<br><br></div>Regards,<br></div>Gabor<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 4, 2015 at 3:44 PM, John Lenton <span dir="ltr"><<a href="mailto:john.lenton@canonical.com" target="_blank">john.lenton@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2 November 2015 at 11:20, Gábor Paller <<a href="mailto:gaborpaller@gmail.com">gaborpaller@gmail.com</a>> wrote:<br>
> Can this be the BeagleBone's SD card filesystem?<br>
<br>
</span>I don't know what is doing it; as far as I can tell, you've modified<br>
the base system (that's supposed to be readonly), so I have no way to<br>
guess what's going on. I can't reproduce your issue on a snappy<br>
ubuntu-core bbb (and as far as I know that what you're seeing doesn't<br>
happen is covered by our automated integration tests).<br>
<br>
If I had to guess I'd say you've somehow changed the order in which<br>
things happen on boot, or otherwise made it so that the firstboot<br>
stamp is either not written or written to something ephemeral, and the<br>
firstboot run is being done every time.<br>
<br>
But that's all guesswork on my part.<br>
</blockquote></div><br></div>