On Sat, 09.02.13 02:58, Michael Biebl (mbi...@gmail.com) wrote:
> basically works. I idid get a few error messages when the container
> was booted like
>
> Netlink failure for request 1: Operation not permitted
> Failed to configure loopback device: Operation not permitted
> Failed to enable ctrl
On Sat, 9 Feb 2013 02:58:05 +0100 Michael Biebl wrote:
> >> yes ... and there was a /usr/share/sysvinit/inittab, just not
> >> in /etc/inittab for reasons unknown ... i symlinked it and it gets
> >> a lot further (but not to a login prompt) now ...
> >
> > Uh, that's weird. Michael, Tollef, any id
2013/2/9 Michael Biebl :
> # in a F18 system
> systemd-nspawn -b -D /srv/sid/ /bin/systemd
This looks like that then:
Inside the container:
root@pluto:~# systemd-cgls
└ system
├ 1 /lib/systemd/systemd /bin/systemd
├ console-shell.service
│ ├ 89 bash
│ └ 97 systemd-cgls
├ rsyslog.service
2013/2/8 Lennart Poettering :
> On Fri, 08.02.13 13:31, Jake Edge (j...@lwn.net) wrote:
>> On Fri, 8 Feb 2013 21:19:22 +0100 Lennart Poettering wrote:
>> > Well, you'll have to build systemd inside the container, because you
>> > need to build it against the Debian version of the libraries, of
>>
On Sat, 02.02.13 14:17, Arthur Taylor (a...@ified.ca) wrote:
> Hello systemd developers
>
> TL;DR: On a VT which X is running, messing with KDSKBMODE on
> underneath X at best has no affect and at worst breaks keyboard input
> badly. In the short term, systemd should stop calling this ioctl
> bec
Dump coredump to /var/log/journal/MACHINE-ID/coredump/COMM.DUMP-ID128.
If can't, fallback to default behavior (dump to journal 24Mb of data).
Optionaly introduce SHA1 hashsum for incoming coredumps, if they are
going out of journal
---
Makefile.am | 10 ++
src/journal/coredump.
On 08/02/13 20:51, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Feb 08, 2013 at 07:51:48PM +, Steven Hiscocks wrote:
On 06/02/13 00:55, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Feb 05, 2013 at 11:45:10PM +, Steven Hiscocks wrote:
On 05/02/13 23:00, Zbigniew Jędrzejewski-Szmek wrote:
O
On Fri, Feb 8, 2013 at 12:08 AM, Thomas H.P. Andersen wrote:
> On Thu, Feb 7, 2013 at 10:30 PM, Zbigniew Jędrzejewski-Szmek
> wrote:
>> On Thu, Feb 07, 2013 at 12:15:24PM -0800, Thomas H.P. Andersen wrote:
>>> src/test/test-env-replace.c | 135
>>> +++-
>
On Fri, 08.02.13 13:31, Jake Edge (j...@lwn.net) wrote:
>
> On Fri, 8 Feb 2013 21:19:22 +0100 Lennart Poettering wrote:
>
> > Well, you'll have to build systemd inside the container, because you
> > need to build it against the Debian version of the libraries, of
> > course. Building it inside t
On 02/07/2013 10:09 AM, Frederic Crozat wrote:
> We have exactly the same issue on openSUSE with some network services,
> and we are using --ignore-dependencies in those case (because --no-block
> is not always the "right" solution).
Yeah. I thrashed around for a couple of days until I finally yo
On 02/07/2013 06:13 AM, Colin Guthrie wrote:
> Also re the initscripts tweaks and the if statement proposed in the bug,
> there is a SYSTEMCTL_IGNORE_DEPENDENCIES=1 env var you can export that
> will make "service openvswitch start" pass the --ignore-dependencies
> argument if it redirects to syste
On Fri, Feb 08, 2013 at 07:51:48PM +, Steven Hiscocks wrote:
> On 06/02/13 00:55, Zbigniew Jędrzejewski-Szmek wrote:
> >On Tue, Feb 05, 2013 at 11:45:10PM +, Steven Hiscocks wrote:
> >>On 05/02/13 23:00, Zbigniew Jędrzejewski-Szmek wrote:
> >>>On Tue, Feb 05, 2013 at 09:22:46PM +, Steve
---
src/journal/coredumpctl.c | 262 +-
1 file changed, 213 insertions(+), 49 deletions(-)
diff --git a/src/journal/coredumpctl.c b/src/journal/coredumpctl.c
index b6e5581..b5d70a0 100644
--- a/src/journal/coredumpctl.c
+++ b/src/journal/coredumpctl.c
@
]] Lennart Poettering
> So, humm, are environment vars allowed to include newlines? Should we
> filter them out? We need to do some research...
IFS traditionally contains a newline. AFAIK env vars can contain
anything but nulls, including invalid UTF-8
--
Tollef Fog Heen
UNIX is user friendl
On Fri, 8 Feb 2013 21:19:22 +0100 Lennart Poettering wrote:
> Well, you'll have to build systemd inside the container, because you
> need to build it against the Debian version of the libraries, of
> course. Building it inside the container should be easy, even if you
> cannot make the container b
On Fri, 08.02.13 13:00, Jake Edge (j...@lwn.net) wrote:
> > What I did is this: I installed Debian unstable into a directory with
> > debootstrap, then installed Debian's systemd .deb into it and then
> > manually built systemd git in it and simply install it into the
> > container's /usr. That wo
On Fri, 8 Feb 2013 20:24:55 +0100 Lennart Poettering wrote:
> On Fri, 08.02.13 09:54, Jake Edge (j...@lwn.net) wrote:
>
> >
> > so, i'm trying to follow along with systemd for admins part 6 and
> > hitting the following problem on Fedora 18 (audit=0, fwiw):
> >
> > # debootstrap --arch=amd64 uns
On 06/02/13 00:55, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Feb 05, 2013 at 11:45:10PM +, Steven Hiscocks wrote:
On 05/02/13 23:00, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Feb 05, 2013 at 09:22:46PM +, Steven Hiscocks wrote:
On 05/02/13 02:49, Zbigniew Jędrzejewski-Szmek wrote:
H
On Fri, 08.02.13 09:54, Jake Edge (j...@lwn.net) wrote:
>
> so, i'm trying to follow along with systemd for admins part 6 and
> hitting the following problem on Fedora 18 (audit=0, fwiw):
>
> # debootstrap --arch=amd64 unstable debian/
> ...
> (needed to put /sbin in my path in order for deboots
so, i'm trying to follow along with systemd for admins part 6 and
hitting the following problem on Fedora 18 (audit=0, fwiw):
# debootstrap --arch=amd64 unstable debian/
...
(needed to put /sbin in my path in order for debootstrap to work, btw)
# systemd-nspawn -D debian/ /sbin/init
Spawning nam
On Fri, Feb 8, 2013 at 5:03 PM, Colin Guthrie wrote:
> 'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 08/02/13 12:14 did
> gyre and gimble:
>> On Fri, Feb 08, 2013 at 11:48:36AM +, Colin Guthrie wrote:
>>> On some really old hardware, the default timeout of 120 (which may even
>>> be reduce
'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 08/02/13 12:14 did
gyre and gimble:
> On Fri, Feb 08, 2013 at 11:48:36AM +, Colin Guthrie wrote:
>> On some really old hardware, the default timeout of 120 (which may even
>> be reduced further on the command line) is insufficient.
>>
>> While s
On Fri, 08.02.13 12:27, Stef Bon (stef...@gmail.com) wrote:
>
> 2013/2/8 Lennart Poettering :
> > On Wed, 06.02.13 14:24, Stef Bon (stef...@gmail.com) wrote:
> >
> >> Ok, when logind sends out a message (after seat added or removed) it's
> >> up to the services like gdm(?) what to do with it: use
On Fri, Feb 08, 2013 at 11:48:36AM +, Colin Guthrie wrote:
> On some really old hardware, the default timeout of 120 (which may even
> be reduced further on the command line) is insufficient.
>
> While such cases are specialist and (nowadays) relatively rare, it is
> still nice to be able to p
On some really old hardware, the default timeout of 120 (which may even
be reduced further on the command line) is insufficient.
While such cases are specialist and (nowadays) relatively rare, it is
still nice to be able to provide a method to increase the timeout
when needed.
Bug Link: https://b
'Twas brillig, and Kay Sievers at 08/02/13 11:21 did gyre and gimble:
> On Fri, Feb 8, 2013 at 12:05 PM, Colin Guthrie wrote:
>> 'Twas brillig, and Kok, Auke-jan H at 08/02/13 08:04 did gyre and gimble:
>>> On Thu, Feb 7, 2013 at 3:38 PM, Lennart Poettering
>>> wrote:
On Thu, 07.02.13 16:57,
2013/2/8 Lennart Poettering :
> On Wed, 06.02.13 14:24, Stef Bon (stef...@gmail.com) wrote:
>
>> Ok, when logind sends out a message (after seat added or removed) it's
>> up to the services like gdm(?) what to do with it: use it as docking
>> station or to start a new session (eg a real seat) ( whe
On Fri, Feb 8, 2013 at 12:05 PM, Colin Guthrie wrote:
> 'Twas brillig, and Kok, Auke-jan H at 08/02/13 08:04 did gyre and gimble:
>> On Thu, Feb 7, 2013 at 3:38 PM, Lennart Poettering
>> wrote:
>>> On Thu, 07.02.13 16:57, Bryan Duff (bd...@ecessa.com) wrote:
>>>
Would it be possible to add t
'Twas brillig, and Kok, Auke-jan H at 08/02/13 08:04 did gyre and gimble:
> On Thu, Feb 7, 2013 at 3:38 PM, Lennart Poettering
> wrote:
>> On Thu, 07.02.13 16:57, Bryan Duff (bd...@ecessa.com) wrote:
>>
>>> Would it be possible to add this as some kind of option to systemd-fsck?
>>>
>>> In my case
Dump coredump to /var/log/journal/MACHINE-ID/coredump/COMM.DUMP-ID128.
If can't, fallback to default behavior (dump to journal 24Mb of data).
---
Makefile.am| 1 +
src/journal/coredump.c | 199 +
2 files changed, 135 insertions(+), 65 d
]] Lennart Poettering
> What I am a bit unsure about still though is whether we should add this
> jitter by default to all timer units, dependending on "how precise" the
> time specification was. i.e. if the user specifies a time to the second,
> then add jitter of < 1s to it, if he specified a t
Fixes this bug:
alxchk > systemctl --user set-environment A=B
alxchk > systemctl --user show-environment | grep ^A=
A=B
alxchk > systemctl --user daemon-reexec
alxchk > systemctl --user show-environment | grep ^A=
alxchk >
alxchk > dctl set-environment A=$(echo -e "A\nB")
alxchk > dctl show-environ
On Thu, Feb 7, 2013 at 3:38 PM, Lennart Poettering
wrote:
> On Thu, 07.02.13 16:57, Bryan Duff (bd...@ecessa.com) wrote:
>
>> Would it be possible to add this as some kind of option to systemd-fsck?
>>
>> In my case there was a situation where ext3 would not mount because
>> of a timestamp issue t
33 matches
Mail list logo
