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

[Michał Zegan]

W dniu 14.06.2022 o 07:57, Ulrich Windl pisze:
>>>> 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.
>>
>> 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
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xE6516A8A8E25955D.asc
Type: application/pgp-keys
Size: 10971 bytes
Desc: OpenPGP public key
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20220614/3af18766/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20220614/3af18766/attachment-0001.sig>