In the interest of having a working system, I reverted that machine to systemd version 230-7. Unsurprisingly, the problem went away.
I’ll try re-installing 231-1 and commenting that line. I’ll probably have a chance tonight. I’ll report when I have something. It may be worth noticing that other things failed as well when 231-1 was in. I’m attaching a ‘grep -i fail -C20’ of the screen log. Of particular note are “Failed to start Raise network interfaces” and “Failed to start Login Service.” Are there other places where I should remove a “SystemCallFilter” ?
screenlog.xz
Description: Binary data
On Jul 28, 2016, at 1:24 PM, Michael Biebl <bi...@debian.org> wrote: > Am 28.07.2016 um 22:01 schrieb Rick Thomas: >> No. This is a stock kernel. It’s available from both testing and unstable >> repos. The machine itself is a SheevaPlug. Nothing custom about it. >> >> What makes you think it’s custom? > > This was more of a question then a statement. > I wanted to rule out, that the kernel was missing any relevant features. > > I assume the previous version worked properly and the addition of > > SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module @mount > @obsolete @raw-io > > is causing the problem? If you comment out that line from > systemd-journald.service, does it start properly? > > SystemCallFilter uses libseccomp, maybe libseccomp on armel is not fully > functional and we need to reassign this. > > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? >
