No network in chroot environment

[Tom H]

On Fri, Jan 24, 2020 at 8:42 PM Volker Wysk <post at volker-wysk.de> wrote:
> Am Freitag, den 24.01.2020, 20:00 +0100 schrieb Tom H:
>> On Fri, Jan 24, 2020 at 7:16 PM Volker Wysk <post at volker-wysk.de>
>> wrote:


>>> I'm migrating my old system to a new SSD in a new computer, and
>>> come to the point to set up the new root file system in a chroot:
>>>
>>> cryptsetup luksOpen /dev/nvme0n1p3 nvme0n1p3_crypt
>>> mount /dev/mapper/nvme0n1p3_crypt /mnt/rootneu
>>> mount --rbind /dev /mnt/rootneu/dev
>>> mount --rbind /proc /mnt/rootneu/proc
>>> mount --rbind /sys /mnt/rootneu/sys
>>> mount /dev/nvme0n1p2 /mnt/rootneu/boot
>>> mount /dev/nvme0n1p1 /mnt/rootneu/boot/efi
>>> chroot /mnt/rootneu
>>>
>>> This works, but the network in the chroot-ed environment isn't
>>> available:
>>>
>>> Wartung1804 / % LANG=C ping heise.de
>>> ping: heise.de: Name or service not known
>>>
>>> In the original system, it's fine:
>>> v at Wartung1804:~$ LANG=C ping heise.de
>>> PING heise.de(redirector.heise.de (2a02:2e0:3fe:1001:302::)) 56
>>> data
>>> bytes
>>> 64 bytes from redirector.heise.de (2a02:2e0:3fe:1001:302::):
>>> icmp_seq=1
>>> ttl=57 time=15.0 ms
>>> ...
>>>
>>> So what happened to the network..? Might the "mount --rbind ..."
>>> commands be incomplete?
>>
>> "/etc/resolv.conf" is probably a dangling symlink.
>
> You're almost right. It points to an empty file.

I would've expected "/run" in the chrooted systen to be empty...


> I'd like to do this cleanly, like it is supposed to be done. I don't
> fully understand all of the following of what you've written.
>
>> 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 wonder whether bind-mounting "/run" would work and wouldn't have
>> any downsides. I've never tried it; I've never even tnought of it
>> before!
>
> This sounds good, if it works.

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


>> PS: "/proc" isn't usually bind-mounted.
>
> You mean, this shouldn't be done: "mount --rbind /proc
> $mountpoint/proc", but instead: "mount -t proc proc
> "$mountpoint"/proc", right?

Yes.


>> PPS: There's a recommendation to make the bind-mounted filesystems
>> slaves for systemd.
>
> I don't know what systemd slaves are. But this doesn't really have to
> be done, right?

They're not systemd slaves, they're bind-mounts that are marked as slaves.

I noticed a long time ago that nspwn set up slave bind-mounts and
mentioned it to a ex-colleague who's a Gentoo sysadmin. He replied
that Gentoo recommended the use of slave bind-mounts for systemd.

In general, it makes sense to use slave bind-mounts, with or without
systemd, because you don't want a chrooted system to make changes to
/dev /proc /sys (if it can do so) and have those changes propagate to
the chrooting system. I'm considering changing my chroot script not to
use bind-mounts, like the Arch installation scripts.


>> PPPS: I use for Gentoo/Funtoo
>>
>> mount -t proc proc "$mountpoint"/proc
>
> Is there a particular reason for using "-t proc proc" rather than "
> --rbind /proc"?

This is how I learned to set up a chroot. Maybe there was/is a
technical reason. Maybe it's a cargo-cult procedure. I'm going to
re-read the Gentoo instructions (which I haven't read in at least 10
years, so they may have changed) and the Funtoo instructions (which
I've never read) to see what they recommend. I'm also going to take a
look at debootstrap; I vaguely remember seeing bind-mounts in it
whenever it was that I read it. The Arch function above shows that you
don't have to use bind-mounts for dev/proc/sys, so maybe you can mix
and match mounts and bind-mounts for them depending on how much you
feel like typing (with choosing all bind-mounts being shorter).


>> for apifs in dev sys ; do
>> mount -o rbind /"$apifs" "$mountpoint"/"$apifs"
>> mount --make-rslave "$mountpoint"/"$apifs"
>> done
>
> "--make-rslave" isn't fully documented in the mount man page (of Ubuntu
> 18.04). It only says "The following commands allow one to recursively
> change the type of all the mounts under a given mountpoint.".

If you bind-mount "/a" onto "/b".

If "/b" is marked as shared, changes under "/a" propagete to "/b" and
changes under "/b" propagate to "/a".

If "/b" is marked as a slave, changes under "/a" propagete to "/b" and
changes under "/b" don't propagate to "/a".

There's also "private" and "unbindable".