W dniu 14.06.2022 o 07:57, Ulrich Windl pisze:
Colin Guthrie <gm...@colin.guthr.ie> schrieb am 13.06.2022 um 16:34 in
Nachricht <t87hth$49u$1...@ciao.gmane.io>:

Ulrich Windl wrote on 13/06/2022 14:42:
Colin Guthrie <gm...@colin.guthr.ie> schrieb am 13.06.2022 um 14:58 in
Nachricht <t87c9t$lon$1...@ciao.gmane.io>:
Ulrich Windl wrote on 13/06/2022 09:09:
Hi!

Two questions:
1) Why can't I use "systemctl start network" in a chroot environment (e.g.
mounting the system from a rescue medium to fix a defective kernel)? When I
try I get: "Running in chroot, ignoring command 'start'"
2) How can I start the network using systemd?
You may wish to consider "booting" the container rather than just chrooting.
No container involved; an unbootable system instead, and I'd like to have
networking available for repair.
So obviously I cannot boot. Without systemd it wouldn't be a problem.
So you're not running an init system but you want the (not-running) init
system to run something for you?
I don't understand:
The rescue system I'm using (SLES 14 SP3) uses systemd, and the system that 
woon't boo is also using systemd (SLES15 SP3).

If you're wanting to repair a system, and you need networking then bring
up the network in the repair image before chrooting surely? (i.e. what
Mantas said)
Well the configuration files are not in the generic rescue system, but in the 
system that won't boot (I think I had explained that).
Also things became much more complicated with systemd and wickedd and all that 
stuff.

If you want to run the network inside the (broken) system you're trying
to repair, then just run the networking scripts or program manually.
i.e. run whatever /etc/init.d/network says or whatever ExecStart= says
in /usr/lib/systemd/network.service says (paths may vary).
There are no files inside /etc/init.d/.

There will be loads of other stuff that the init system does that won't
be in place (e.g. tmpfiles, etc.) which you may or may not need to setup
manually too, but you can likely get it running.

  > Without systemd it wouldn't be a problem.

Sure when "init" was just a bundle of scripts, you could run one of the
scripts it runs and hope for the best. You can generally still do that,
but just don't expect asking a non-running program to do it for you to work!
Still I don't understand: systemd is running.

on the host. daemons usually read configuration, including service files, from the place they run from. systemd is not running from chroot so it will read services from outside of chroot, doing othervise would be extremely weird behavior.

note contrary to sysvinit you are not running service scripts, but you communicate with an already running systemd instance to start a service, so because systemd runs from outside of chroot it cannot start a service as if it was in a chroot, nor can this service read config files from chroot.

You would literally need running systemd copy related to the chroot which you cannot do without namespacing, and you would need network interface in that ns.

would be an interesting experiment to do without container software tbh.


Regards,
Ulrich

Col



Attachment: OpenPGP_0xE6516A8A8E25955D.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to