Lennart Poettering wrote
But this means that wicked is generally incompatible with NFS-root.
Fortunately not! The SuSE support pointed me to an option that wasn't
documented in the SLES 12 manual section about wicked (but that I could
have found when googling with the correct keywords :-():
Lennart Poettering wrote
Normally the network mounts should be ordered after network.target,
and wicked before that. Since in systemd the shutdown order is always
the inverse of the startup order this would mean that the mounts are
removed first, and wicked only stopped afterwards.
I guess
On Fri, Jul 3, 2015 at 5:03 PM, Frank Steiner
fsteiner-ma...@bio.ifi.lmu.de wrote:
Lennart Poettering wrote
Normally the network mounts should be ordered after network.target,
and wicked before that. Since in systemd the shutdown order is always
the inverse of the startup order this would
On Fri, 03.07.15 16:03, Frank Steiner (fsteiner-ma...@bio.ifi.lmu.de) wrote:
Lennart Poettering wrote
Normally the network mounts should be ordered after network.target,
and wicked before that. Since in systemd the shutdown order is always
the inverse of the startup order this would mean
On Fri, 03.07.15 17:22, Andrei Borzenkov (arvidj...@gmail.com) wrote:
On Fri, Jul 3, 2015 at 5:03 PM, Frank Steiner
fsteiner-ma...@bio.ifi.lmu.de wrote:
Lennart Poettering wrote
Normally the network mounts should be ordered after network.target,
and wicked before that. Since in systemd
On Thu, 02.07.15 12:24, Frank Steiner (fsteiner-ma...@bio.ifi.lmu.de) wrote:
Hi,
for our diskless clients I setup the network and the root fs in the
kernel/initrd and do two additional mounts in the initrd which are
specific for every client.
I understand the boot concept with its
Hi,
Lennart Poettering wrote
1. I want to keep the network running. To avoid problems with dependencies
I had to keep it enabled although all the stuff is done in the
kernel/initrd.
Thus, it shuts down during reboot and the diskless client hangs
of course.
This really depends
On Fri, 03.07.15 12:14, Frank Steiner (fsteiner-ma...@bio.ifi.lmu.de) wrote:
Heya,
This really depends on the network management service you are
using. networkd won't shut down any network connections when you
terminate it for example.
Which one are you using?
it's wicked in SLES
On Thu, Jul 2, 2015 at 1:24 PM, Frank Steiner fsteiner-ma...@bio.ifi.lmu.de
wrote:
Hi,
for our diskless clients I setup the network and the root fs in the
kernel/initrd and do two additional mounts in the initrd which are
specific for every client.
I understand the boot concept with its
Hi,
for our diskless clients I setup the network and the root fs in the
kernel/initrd and do two additional mounts in the initrd which are
specific for every client.
I understand the boot concept with its dependencies and ordering but I've
no idea how to influence the shutdown process in two
Mantas Mikulėnas wrote
If the 'main' network.service doesn't do anything anyway (since the
network is already up), you can replace it entirely with Type=oneshot,
ExecStart=/bin/true, RemainAfterExit=yes, essentially a service that
does nothing at all (but still satisfies dependencies).
Ok,
11 matches
Mail list logo
