No network in chroot environment

Sat Jan 25 12:17:21 UTC 2020

!?!§% I've lost the mail which I habe been writing. Stupid Evolution.

Am Freitag, den 24.01.2020, 23:57 +0100 schrieb Tom H:
> > > 

> On Fri, Jan 24, 2020 at 8:42 PM Volker Wysk <post at volker-wysk.de>
> wrotOn 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...
> 
> e:
> > Am Freitag, den 24.01.2020, 20:00 +0100 schrieb Tom H:
> > 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'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".

> > > 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

What means "API", and what does it tell us?

> 
> 
> > > 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.

What's the difference? Shouldn't it be the same?

> 
> 
> > > 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".

Great! That's exactly what is needed. I'll do:

mount --rbind /run $mountpoint/run
mound --rslave $mountpoint/run
(...)
chroot $mountpoint

Cheers,
Volker