Kernel hackers need access to the debugfs filesystem. For instance, see
the performance subsystem (tools/perf in the kernel tree); we should let
all users, not just root, run the perf tool to collect performance
information about their programs by default.
Cc: Lennart Poettering
Am 01.10.2013 02:58, schrieb Lennart Poettering:
Originally the intention was that root-fsck.service would run fsck for
the root device, anf fsck@.service would be used for the rest. The
difference is mostly one about ordering, i.e. root-fsck.service is the
only one that is fine with the fs
On Fri, Oct 04, 2013 at 11:34:44AM +0200, Thomas Bächler wrote:
Am 01.10.2013 02:58, schrieb Lennart Poettering:
Originally the intention was that root-fsck.service would run fsck for
the root device, anf fsck@.service would be used for the rest. The
difference is mostly one about ordering,
Am 04.10.2013 13:52, schrieb Zbigniew Jędrzejewski-Szmek:
Colin had the great idea that we drop mask root-fsck.service in
/run/systemd/system/ when we run fsck in initrd. For example, the initrd
generator could add a service to the initrd that creates the symlink and
a .d snippet that makes
On Fri, Oct 4, 2013 at 7:30 AM, Ramkumar Ramachandra artag...@gmail.com wrote:
Kernel hackers need access to the debugfs filesystem. For instance, see
the performance subsystem (tools/perf in the kernel tree); we should let
all users, not just root, run the perf tool to collect performance
On Fri, 04.10.13 11:00, Ramkumar Ramachandra (artag...@gmail.com) wrote:
Kernel hackers need access to the debugfs filesystem. For instance, see
the performance subsystem (tools/perf in the kernel tree); we should let
all users, not just root, run the perf tool to collect performance
On Fri, Oct 04, 2013 at 04:50:30PM +0200, Lennart Poettering wrote:
On Fri, 04.10.13 11:00, Ramkumar Ramachandra (artag...@gmail.com) wrote:
Kernel hackers need access to the debugfs filesystem. For instance, see
the performance subsystem (tools/perf in the kernel tree); we should let
all
Hi,
I want to build sytemd in cross-build environment.
One from many needed dependencies is libcap which is really old and
isn't cross-build friendly.
It looks like libcap-ng is kind of successor and I can build this lib in
my cross-build environment.
Is there any way to build systemd with
On Fri, 04.10.13 17:12, Warpme (war...@o2.pl) wrote:
Hi,
I want to build sytemd in cross-build environment.
One from many needed dependencies is libcap which is really old and
isn't cross-build friendly.
It looks like libcap-ng is kind of successor and I can build this
lib in my cross-build
@Andrey, the full log can be found here, the link was there before also:
http://pastebin.com/wbr04AQw (systemd-207)
It's quite silent about the cause for the timeout, though.
I've been debugging this for three days now, and I've crystallized a little
bit of information.
1. If I boot the system
Next reboot after the user@0.service start/stop cycle was a quick one. It
looks as something gets messed up upon logging in. And if not resolved, the
system has problems shutting down.
On 4 October 2013 19:31, Toms Seisums toms.seis...@gmail.com wrote:
@Andrey, the full log can be found here,
if you need a receipt to crosscompile libcap see:
https://github.com/OpenELEC/OpenELEC.tv/blob/master/packages/devel/libcap/build
basically you must compile _makenames first with the hosttools:
make CC=$HOST_CC -C libcap _makenames
as a second step you crosscompile libcap like:
make
В Fri, 4 Oct 2013 19:31:43 +0300
Toms Seisums toms.seis...@gmail.com пишет:
@Andrey, the full log can be found here, the link was there before also:
http://pastebin.com/wbr04AQw (systemd-207)
It's quite silent about the cause for the timeout, though.
How do you generate it? It lacks any
All of those are shutdown messages, generated by:
http://freedesktop.org/wiki/Software/systemd/Debugging/#shutdowncompleteseventually
In case boot messages are needed, I'll be able to provide them on monday.
If I need to change some kernel parameters for shutdown to get more verbose
output, I'd
On Fri, Oct 4, 2013 at 9:37 AM, Toms Seisums toms.seis...@gmail.com wrote:
[object Object]
Look at Gmail failing flat on its face... lol
Aside from that, can you perhaps try this patch:
--- systemd-user-sessions.service 2013-10-02 15:37:14.181330287 -0700
+++ systemd-user-sessions.service
On 10/4/13 6:38 PM, Stephan Raue wrote:
if you need a receipt to crosscompile libcap see:
https://github.com/OpenELEC/OpenELEC.tv/blob/master/packages/devel/libcap/build
basically you must compile _makenames first with the hosttools:
make CC=$HOST_CC -C libcap _makenames
as a second
On Fri, Oct 4, 2013 at 8:57 PM, Kok, Auke-jan H
auke-jan.h@intel.com wrote:
On Fri, Oct 4, 2013 at 9:37 AM, Toms Seisums toms.seis...@gmail.com wrote:
[object Object]
Look at Gmail failing flat on its face... lol
Aside from that, can you perhaps try this patch:
---
Another dbus question:
Is it expected that a UnitNew and UnitRemove are sent when I use
org.freedesktop.DBus.Properties.Get or GetAll? This also happens with
`systemctl status doesnt-exist.service`
Here is an example of what I am seeing:
18 matches
Mail list logo