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 would
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
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 allowed
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 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
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 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 the
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 stubs
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[1612]: enp1s6
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
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 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
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
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, waiting
On Sun, May 03, 2015 at 06:06:58PM +0300, Andrei Borzenkov wrote:
В Sun, 3 May 2015 16:17:15 +0200
Lennart Poettering lenn...@poettering.net пишет:
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
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 system
В Sun, 3 May 2015 16:17:15 +0200
Lennart Poettering lenn...@poettering.net пишет:
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
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
В Sun, 3 May 2015 15:33:56 +
Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет:
On Sun, May 03, 2015 at 06:06:58PM +0300, Andrei Borzenkov wrote:
В Sun, 3 May 2015 16:17:15 +0200
Lennart Poettering lenn...@poettering.net пишет:
On Sat, 02.05.15 13:16, Zbigniew Jędrzejewski-Szmek
On Sun, May 3, 2015 at 6:18 PM, 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 Sun, May 3, 2015 at 6:54 PM, 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?
pid 1 is allowed to catch
Kai Krakow hurikha...@gmail.com 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
22 matches
Mail list logo
