Yes! At long last 231-6 seems to have cleared the systemd issue I was
observing on Raspberry Pi:
--
root@pi ~ # systemctl status
● pi
State: running
Jobs: 0 queued
Failed: 0 units
On 30 August 2016 at 13:43, Felipe Sateler wrote:
> On 30 August 2016 at 13:32, Pete Batard wrote:
>> On 2016.08.30 17:30, Felipe Sateler wrote:
>>>
>>> I managed to get the config from a jessie rpi by loading the 'configs'
>>> module (sudo modprobe configs).
Okay.
I have logged issue #651
(https://github.com/raspberrypi/firmware/issues/651) with the rpi team
so that they try to sort their SECCOMP configuration in future kernels.
Regards,
/Pete
On 30 August 2016 at 13:32, Pete Batard wrote:
> On 2016.08.30 17:30, Felipe Sateler wrote:
>>
>> I managed to get the config from a jessie rpi by loading the 'configs'
>> module (sudo modprobe configs). After that the config is found on
>> /proc/config.gz
>
>
> Yeah, I just
On 2016.08.30 17:30, Felipe Sateler wrote:
I managed to get the config from a jessie rpi by loading the 'configs'
module (sudo modprobe configs). After that the config is found on
/proc/config.gz
Yeah, I just discovered the same after I replied.
This is also documented on the official rpi
On 30 August 2016 at 13:26, Pete Batard wrote:
> Thanks Felipe.
>
> I guess with the new detection process, the resurgence of the issue is
> starting to make sense now.
>
> For the record, I am using one of the latest official Raspberry Pi kernels
> from
Thanks Felipe.
I guess with the new detection process, the resurgence of the issue is
starting to make sense now.
For the record, I am using one of the latest official Raspberry Pi
kernels from https://github.com/raspberrypi/firmware (which I get
indirectly through the
On 29 August 2016 at 13:13, Pete Batard wrote:
> Well, adding 'systemd.log_level=debug' to my kernel options made the system
> enter emergency mode...
>
> And I can't get the very beginning of the log then (even though I also tried
> to increase the buffer size by adding
On 29 August 2016 at 12:10, Pete Batard wrote:
> Please find my boot log. Note that I've tried commenting out
> 'MemoryDenyWriteExecute=yes' in the various .service config files, but it
> didn't help.
>
> If you need anything else, please let me know.
This log is not verbose. Could
Please find my boot log. Note that I've tried commenting out
'MemoryDenyWriteExecute=yes' in the various .service config files, but
it didn't help.
If you need anything else, please let me know.
Regards,
/Pete
[0.00] Booting Linux on physical CPU 0xf00
[0.00] Initializing
Control: tags -1 moreinfo
Control: found -1 231-5
On 28 August 2016 at 17:46, Pete Batard wrote:
> On 2016.08.28 15:37, Felipe Sateler wrote:
>>
>> Could you try 231-5 from unstable?
>
>
> Oops, I mean 231-5 broke it. I'm seeing the issue back in 231-5 and not
> 231-4 as I
On 2016.08.28 15:37, Felipe Sateler wrote:
Could you try 231-5 from unstable?
Oops, I mean 231-5 broke it. I'm seeing the issue back in 231-5 and not
231-4 as I mentioned earlier.
231-4 seemed to be okay, and it's only when I upgraded to 231-5 that the
problem reappeared.
Regards,
/Pete
On 27 August 2016 at 20:20, Pete Batard wrote:
> ...and 231-4 broke the whole thing down again. :(
Could you try 231-5 from unstable?
--
Saludos,
Felipe Sateler
...and 231-4 broke the whole thing down again. :(
Same error:
root@pi ~ # systemctl status systemd-journald.service
● systemd-journald.service - Journal Service
Loaded: loaded (/lib/systemd/system/systemd-journald.service;
On 14 août 2016 23:38, Pete Batard wrote:
> Didn't fix it for me... :(
Same for me, still broken.
Christian
Didn't fix it for me... :(
I went to an 'apt-get --reinstall install' of every single package that
is listed under 'Description' above (expect -udeb and -dev), and got the
231-2 version alright, but the issue remains exactly the same, even
after a full reboot.
I should point out that I did
On Aug 12, 2016, at 9:21 AM, Pete Batard wrote:
> Okay. I have now gone through a dpkg -i install of all the (non dbgsym) .deb
> I see on your server, and also issued a reboot for good measure, but I still
> see the same problem with journald being failed, along with dependent
Okay. I have now gone through a dpkg -i install of all the (non dbgsym)
.deb I see on your server, and also issued a reboot for good measure,
but I still see the same problem with journald being failed, along with
dependent services
On 12 August 2016 at 11:05, Pete Batard wrote:
> Thanks Felipe.
>
> I installed libsystemd0_231-2_armhf.deb but shouldn't there be a
> systemd_231-2_armhf.deb as well? Strangely there's a
> systemd-dbgsym_231-2_armhf.deb but no non-dbgsym version, as opposed to
> other .debs.
Sorry
Thanks Felipe.
I installed libsystemd0_231-2_armhf.deb but shouldn't there be a
systemd_231-2_armhf.deb as well? Strangely there's a
systemd-dbgsym_231-2_armhf.deb but no non-dbgsym version, as opposed to
other .debs.
The .dsc does mention a 'systemd' binary, and earlier, the idea was to
On 8 August 2016 at 10:03, Felipe Sateler wrote:
> On 8 August 2016 at 02:59, Pete Batard wrote:
>> Thanks Felipe.
>>
>> I'm afraid it's still not completing successfully though:
>
> Gah, I'm terribly sorry. I have a fix here, but I'm testbuilding first
>
On 8 August 2016 at 02:59, Pete Batard wrote:
> Thanks Felipe.
>
> I'm afraid it's still not completing successfully though:
Gah, I'm terribly sorry. I have a fix here, but I'm testbuilding first
before asking you to do that again. I'll let you know as soon as I
have built it.
--
Thanks Felipe.
I'm afraid it's still not completing successfully though:
../src/test/test-execute.c: In function ‘test_exec_systemcallfilter’:
../src/test/test-execute.c:120:14: error: implicit declaration of
function
On 6 August 2016 at 05:20, Pete Batard wrote:
> Since Rick hasn't replied, and I've been encountering the same issue on a
> Raspberry Pi 2 model B running sid, I've been trying the steps mentioned
> above.
Hi Pete,
I have updated the source package hopefully fixing this issue.
Since Rick hasn't replied, and I've been encountering the same issue on
a Raspberry Pi 2 model B running sid, I've been trying the steps
mentioned above.
However the post-build tests failed with the following:
-
> On Aug 3, 2016, at 3:58 PM, Felipe Sateler wrote:
>
> On 3 August 2016 at 16:44, Rick Thomas wrote:
>>
>> On Aug 3, 2016, at 9:06 AM, Felipe Sateler wrote:
>>
>>> On 1 August 2016 at 18:32, Rick Thomas
On 3 August 2016 at 16:44, Rick Thomas wrote:
>
> On Aug 3, 2016, at 9:06 AM, Felipe Sateler wrote:
>
>> On 1 August 2016 at 18:32, Rick Thomas wrote:
>>>
>>> Thanks, Filipe!
>>>
>>> What do we have to do at this point to test this
On Aug 3, 2016, at 9:06 AM, Felipe Sateler wrote:
> On 1 August 2016 at 18:32, Rick Thomas wrote:
>>
>> Thanks, Filipe!
>>
>> What do we have to do at this point to test this and then translate it into
>> a patch?
>
> OK, so I have a
Am 03.08.2016 um 17:26 schrieb Felipe Sateler:
> Control: forwarded -1 https://github.com/systemd/systemd/issues/3882
> Control: severity -1 serious
> Yes, I'd like upstream's opinion on this first. However, I think this
> bug should be bumped to RC to prevent migration to testing, as this
>
On 1 August 2016 at 18:32, Rick Thomas wrote:
>
> On Aug 1, 2016, at 2:40 PM, Felipe Sateler wrote:
>
>> On 28 July 2016 at 17:04, Michael Biebl wrote:
>>> Am 28.07.2016 um 22:50 schrieb Rick Thomas:
In the interest of having a
Control: forwarded -1 https://github.com/systemd/systemd/issues/3882
Control: severity -1 serious
On 3 August 2016 at 02:15, Michael Biebl wrote:
> Am 01.08.2016 um 23:40 schrieb Felipe Sateler:
>> So I think the kernel should enable SECCOMP.
>
> I agree, unless SECCOMP on arm
On Aug 2, 2016, at 11:15 PM, Michael Biebl wrote:
> Am 01.08.2016 um 23:40 schrieb Felipe Sateler:
>> So I think the kernel should enable SECCOMP.
>
> I agree, unless SECCOMP on arm has some unwanted side-effects.
> Felipe, can you file a bug report against the linux package
Am 01.08.2016 um 23:40 schrieb Felipe Sateler:
> So I think the kernel should enable SECCOMP.
I agree, unless SECCOMP on arm has some unwanted side-effects.
Felipe, can you file a bug report against the linux package accordingly?
> However, I think systemd should also simply (warn and) ignore
On Aug 1, 2016, at 2:40 PM, Felipe Sateler wrote:
> On 28 July 2016 at 17:04, Michael Biebl wrote:
>> Am 28.07.2016 um 22:50 schrieb Rick Thomas:
>>> In the interest of having a working system, I reverted that machine to
>>> systemd version 230-7.
On 28 July 2016 at 17:04, Michael Biebl wrote:
> Am 28.07.2016 um 22:50 schrieb Rick Thomas:
>> 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
Thanks for you help so far, Michael!
Can I ask one last favor on this?
It seems that the bug (whatever it is) depends on things like kernel version
and machine architecture.
So, can you suggest someone who can take this further?
Thanks!
Rick
As I replied to that (did you see it? There may have been some problems with my
email about that time),
commenting out the “SystemCallFilter” did not make the problem go away on
either of the ARM systems.
Another interesting datapoint: I upgraded my PowerMac G4 powerpc machine to
latest Sid
Am 29.07.2016 um 23:29 schrieb Rick Thomas:
> Hmmm… Curiouser and curiouser!
>
> I upgraded a VM (amd64) to latest Sid (with systemd version 231-1). The
> problem is *not* present there.
>
> The problem may be specific to arm hardware? I’ll try it on a PowerPC G4
> (Apple Mac PPC) machine
Hmmm… Curiouser and curiouser!
I upgraded a VM (amd64) to latest Sid (with systemd version 231-1). The
problem is *not* present there.
The problem may be specific to arm hardware? I’ll try it on a PowerPC G4
(Apple Mac PPC) machine later today.
Rick
On Jul 28, 2016, at 5:18 PM, Rick
I upgraded one of my test systems (an armhf Cubox-i4Pro) to Sid.
After rebooting, I saw the same symptoms as on the SheevaPlug.
I commented the line in question in
/lib/systemd/system/systemd-logind.service
and
/lib/systemd/system/systemd-journald.service
There was no corresponding line
Am 28.07.2016 um 22:50 schrieb Rick Thomas:
> 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
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
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
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?
Rick
On Jul 28, 2016, at 3:59 AM, Michael Biebl wrote:
> control: tags -1 + moreinfo
> Am
control: tags -1 + moreinfo
Am 28.07.2016 um 12:08 schrieb Rick Thomas:
> Main PID: 477 (code=exited, status=228/SECCOMP)
...
> Kernel: Linux 4.6.0-1-marvell
That looks like you are using a custom kernel. Is the problem
reproducible with the default Debian Linux kernel?
--
Why is it that all
45 matches
Mail list logo