No network in chroot environment

[Tom H]

On Sat, Jan 25, 2020 at 1:20 PM Volker Wysk <post at volker-wysk.de> wrote:


>>>> One option might be to copy "/run/.../resolv.conf" to the chroot
>>>> before chrooting.
>>>
>>> This sounds like a hack.
>>
>> Before "/etc/resolv.conf" was a symlink, you'd copy
>> "/etc/resolv.conf"
>> to "$mountpoint/etc/resolv.conf". You can call it a hack, but it's
>> what's needed to ensure name resolution.
>
> I've thought about it, and found that there is no clean way to do it.
> The (chrooted) child system is "dead". It's in the state after the
> last shutdown. But the commands which are to be executed, need an
> "alife" system. For instance, the resolver must be operational for
> calling "apt update".

# ls -l "$mountpoint"/etc/resolv.conf
{ it'll be a symlink to one of }
/run/NetworkManager/resolv.conf
/run/resolvconf/resolv.conf
/run/systemd/resolve/stub-resolv.conf
/run/systemd/resolve/resolv.conf
{ AFAIK, by default, it'll be to /run/systemd/resolve/stub-resolv.conf }

# mkdir -p "$mountpoint"/run/systemd/resolve

# cp -L /etc/resolv.conf run/systemd/resolve/stub-resolv.conf

But, if the chrooting and chrooted systems use the same resolv.conf
managejment system, bind-mounting "/run" should take care of chrooted
symlink - and the "cp ..." will fail.


>> I've just looked at the Arch installation scripts. "/run" is the only
>> API filesystem that's bind-mounted:
>>
>>   chroot_add_mount proc "$1/proc" -t proc -o nosuid,noexec,nodev &&
>>   chroot_add_mount sys "$1/sys" -t sysfs -o nosuid,noexec,nodev,ro &&
>>   ignore_error chroot_maybe_add_mount "[[ -d
>> '$1/sys/firmware/efi/efivars' ]]" \
>>       efivarfs "$1/sys/firmware/efi/efivars" -t efivarfs -o
>> nosuid,noexec,nodev &&
>>   chroot_add_mount udev "$1/dev" -t devtmpfs -o mode=0755,nosuid &&
>>   chroot_add_mount devpts "$1/dev/pts" -t devpts -o
>> mode=0620,gid=5,nosuid,noexec &&
>>   chroot_add_mount shm "$1/dev/shm" -t tmpfs -o
>> mode=1777,nosuid,nodev &&
>>   chroot_add_mount /run "$1/run" --bind &&
>>   chroot_add_mount tmp "$1/tmp" -t tmpfs -o
>> mode=1777,strictatime,nodev,nosuid
>
> What means "API", and what does it tell us?

I was just pointing out that Arch doesn't bind-mount /dev /proc /sys