On Sat, 02.05.15 13:16, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
So, the last time we discussed this we figured we should do this
differently, and simply generate systemd-fsck-root.service in the
initrd as well, that uses a different command line internally. The end
result would then
On Fri, 01.05.15 19:38, Kai Krakow (hurikha...@gmail.com) wrote:
> Hello!
>
> If I create a new machine by cloning using systemd-nspawn --template, should
> it remove etc/hostname? It already creates a new machine-id etc, and the
> hostname should probably not be set for a new container in this
В Sun, 3 May 2015 16:17:15 +0200
Lennart Poettering пишет:
> On Sat, 02.05.15 13:16, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
>
> So, the last time we discussed this we figured we should do this
> differently, and simply generate systemd-fsck-root.service in the
> initrd as well, t
Hello
I'm using rigth now a Manjaro distribution (derived from arch). Making some
test, i've discovered that sending SIGABRT (6) to PID 1 (systemd) will
cause system to enter on unstable mode:
after doing this, the system reboot graphic server (at least, it request to
login again) and if you rese
On Sun, 03.05.15 17:18, Víctor Fernández (vfr...@gmail.com) wrote:
> Hello
>
> I'm using rigth now a Manjaro distribution (derived from arch). Making some
> test, i've discovered that sending SIGABRT (6) to PID 1 (systemd) will
> cause system to enter on unstable mode:
>
> after doing this, the
On Fri, 01.05.15 11:39, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
> My container will need access to a Luks encrypted device (/dev/sdd4)
> for its DB.
Only very select devices are accessible from inside containers, more
specifically the ones where it is fully safe to share them between
mul
On Fri, 01.05.15 11:04, Dan Kenigsberg (dan...@redhat.com) wrote:
> On Mon, Apr 20, 2015 at 08:43:21PM +0200, Lennart Poettering wrote:
> > On Fri, 17.04.15 14:19, Nir Soffer (nir...@gmail.com) wrote:
> >
> > > - You may wait for unrelated events that happen to trigger in the same
> > > time, w
On Sun, May 03, 2015 at 06:06:58PM +0300, Andrei Borzenkov wrote:
> В Sun, 3 May 2015 16:17:15 +0200
> Lennart Poettering пишет:
>
> > On Sat, 02.05.15 13:16, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl)
> > wrote:
> >
> > So, the last time we discussed this we figured we should do this
> >
Ok, Thanks for your reply.
But, just out of curiosity, why init process gets down with a SIGABRT and
not with a SIGKILL (9), being this a signal which cannot be caught, blocked
or ignored?
PD: I definitely not try the command above
2015-05-03 17:22 GMT+02:00 Lennart Poettering :
> On Sun, 03.05
On Sun, May 3, 2015 at 6:18 PM, Víctor Fernández wrote:
> Hello
>
> I'm using rigth now a Manjaro distribution (derived from arch). Making
> some test, i've discovered that sending SIGABRT (6) to PID 1 (systemd) will
> cause system to enter on unstable mode:
>
> after doing this, the system reboo
В Sun, 3 May 2015 15:33:56 +
Zbigniew Jędrzejewski-Szmek пишет:
> On Sun, May 03, 2015 at 06:06:58PM +0300, Andrei Borzenkov wrote:
> > В Sun, 3 May 2015 16:17:15 +0200
> > Lennart Poettering пишет:
> >
> > > On Sat, 02.05.15 13:16, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl)
> > > wro
On Sun, May 3, 2015 at 6:54 PM, Víctor Fernández wrote:
> Ok, Thanks for your reply.
>
> But, just out of curiosity, why init process gets down with a SIGABRT and
> not with a SIGKILL (9), being this a signal which cannot be caught, blocked
> or ignored?
>
pid 1 is allowed to catch SIGKILL, and
On Sun, May 03, 2015 at 07:06:14PM +0300, Andrei Borzenkov wrote:
> В Sun, 3 May 2015 15:33:56 +
> Zbigniew Jędrzejewski-Szmek пишет:
>
> > On Sun, May 03, 2015 at 06:06:58PM +0300, Andrei Borzenkov wrote:
> > > В Sun, 3 May 2015 16:17:15 +0200
> > > Lennart Poettering пишет:
> > >
> > > >
Kai Krakow schrieb:
Hello again!
Amended below...
> I'm not sure about this but I suspect that I cannot start a second nspawn
> container with --network-macvlan when another nspawn instance has created
> it before:
>
> # systemd-nspawn -b --network-macvlan=enp4s0
> Spawning container gentoo-my
On Sat, May 2, 2015 at 11:27 AM, arnaud gaboury
wrote:
>
> My host/conatiner networking are both managed by systemd-netwrokd. I
> have a bridge Br0 on host and vb-MyContainer for the conatiner. Both
> have a fix local IP.
>
> I boot container at host boot this way:
>
> ---
On Sun, 03.05.15 17:54, Víctor Fernández (vfr...@gmail.com) wrote:
> Ok, Thanks for your reply.
>
> But, just out of curiosity, why init process gets down with a SIGABRT and
> not with a SIGKILL (9), being this a signal which cannot be caught, blocked
> or ignored?
The kernel refuses to deliver
On Sun, 03.05.15 19:10, Mantas Mikulėnas (graw...@gmail.com) wrote:
> On Sun, May 3, 2015 at 6:54 PM, Víctor Fernández wrote:
>
> > Ok, Thanks for your reply.
> >
> > But, just out of curiosity, why init process gets down with a SIGABRT and
> > not with a SIGKILL (9), being this a signal which c
On Sat, 02.05.15 13:16, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> When testing generators and other utilities, it is extremely useful
> to be able to trigger initramfs behaviour.
Hmm, what about the following solution: instead of checking with
access() for /etc/initrd-release and t
On Sat, 02.05.15 13:16, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> This makes it obvious that those functions are only usable in the
> initramfs.
>
> Also, add a warning when noauto, nofail, or automount is used for the
> root fs, instead of silently ignoring. Using those options wo
On Sun, 03.05.15 18:06, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> > On Sat, 02.05.15 13:16, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl)
> > wrote:
> >
> > So, the last time we discussed this we figured we should do this
> > differently, and simply generate systemd-fsck-root.service in
On Sun, 03.05.15 15:33, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> > systemd-fsck@.service has explicit dependency on
> > systemd-fsck-root.service so other mounts (/usr, anything else?) will
> > be serialized after it. Currently they can run in parallel.
> >
> > Not I think it is a
On Sat, 02.05.15 15:12, Ludovic Gasc (gml...@gmail.com) wrote:
>2. We use heavily AsyncIO module to have async pattern in Python,
>especially for I/O: https://docs.python.org/3/library/asyncio.html
>In the source code of python-systemd, I've seen that you use a C glue to
>interact
On Sat, 02.05.15 07:01, Stephen Gallagher (sgall...@redhat.com) wrote:
> > Well, I guess for now. But note that eventually we hope to move most
> > programs invoked from .desktop into this as systemd services. This
> > then means that the actual sessions will become pretty empty, with
> > only stu
On Sat, 02.05.15 12:00, Paul Menzel (paulepan...@users.sourceforge.net) wrote:
> > /etc/udev/rules.d/10-speed1G-enp1s6.rules
> > ACTION=="add", SUBSYSTEM=="net", RUN+="/usr/sbin/ethtool -s enp1s6
> > advertise 0x20"
> >
> > :03 systemd[1]: Starting Network Service...
> > :05 systemd-networkd[161
On Thu, 30.04.15 15:42, Alban Crequy (al...@endocode.com) wrote:
> > systemd-nspawn nowadays mounts all hierarchies into the container, but
> > mounts all controller hierarchies read-only, and of the name=systemd
> > hierarchy mounts everything read-only, except the subtree the
> > container is al
On Fri, 2015-04-10 at 14:03 +0300, Patrik Flykt wrote:
> Version 2 attempts to resolve IPv6 address assignment issues at run
> time, first by adding IFA_FLAGS, then without.
Hearing no failure reports, this patch has been applied.
Cheers,
Patrik
26 matches
Mail list logo
