[systemd-devel] Antw: Re: Antw: Re: Antw: [EXT] Re: Q: Start network in chroot?

[Ulrich Windl]

>>> Andrei Borzenkov <arvidjaar at gmail.com> schrieb am 14.06.2022 um 08:36 in
Nachricht <41ccac7a-bae8-47a9-f14e-6c94524781ef at gmail.com>:
> On 14.06.2022 08:57, Ulrich Windl wrote:
>>>>> Colin Guthrie <gmane at colin.guthr.ie> schrieb am 13.06.2022 um 16:34 in
>> Nachricht <t87hth$49u$1 at ciao.gmane.io>:
>> 
>>> Ulrich Windl wrote on 13/06/2022 14:42:
>>>>>>> Colin Guthrie <gmane at colin.guthr.ie> schrieb am 13.06.2022 um 14:58 in
>>>> Nachricht <t87c9t$lon$1 at 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.
>>>
> 
> Of course it would for anything that goes beyond simple "ip address add".
> 
>>> 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.
>> 
> 
> I do not understand what you do not understand. systemd is running in
> your rescue system, not in chroot. You want to tell this systemd to use
> configuration inside chroot, but systemd is rescue system is not aware
> of it. It cannot be done unless you start systemd inside of chroot as
> service manager.

Honestly I never had to think about the fact how systemctl communicates with systemd.
Also the message "Running in chroot, ignoring command 'start'" is a very poor one if it should read:
"There is no systemd to communicate with". To me the original message sounds like systemctl refuses to start the unit for some obscure reason.

> 
> And wicked, systemd-networkd, NetwormManager all need functional D-Bus.
> D-Bus is again outside of your chroot with the same caveats. Even
> without systemd in the mix it would be a problem.

Oh, "how many IBM engineers you need to change a light bulb?"
Simplicity has true elegance (Note I'm not talking about being "primitive")

> 
> You have already been told several times - start your networking in
> rescue system before doing chroot. Or use something like systemd-nspawn
> instead of chroot.

I did not even know that systemd-nspawn exists, and actually I don't know what a namespace container is.
I guess life has to be that complicated to keep all those engineers busy...

Regards,
Ulrich