A small thing I learned just now that may help somebody:
I'm trying to rescue a machine that had been rudely interrupted in mid-upgrade. Normally I'd do this by booting off alternate media, mounting/chrooting into the drive and resuming work, but networking didn't work anymore but: only in the chrooted space. It worked fine outside it.
The answer is "/etc/resolv.conf might be stale". It's generated at boot, and was wrong in my chroot.
Editing /etc/resolv.conf (I used 1.1.1.1) fixed it.
Update: Welp. Once again, I find myself in a situation that is unsupported and untested, as I am watching apt absolutely lose its mind at the notion that /proc is unavailable.
@mhoye @falken don't often praise Arch but when I do, it's because of
https://man.archlinux.org/man/arch-chroot.8
packaged for Debian under `arch-install-scripts`
@xlrobot @falken @mhoye the full incantation for a systemd distro is usually this:
mount --types proc /proc /mnt/proc
mount --rbind /sys /mnt/sys
mount --make-rslave /mnt/sys
mount --rbind /dev /mnt/dev
mount --make-rslave /mnt/dev
mount --bind /run /mnt/run
mount --make-slave /mnt/run
The --make-(r)slave steps are important to make sure that all the pseudo-filesystems under those mountpoints get automatically mounted in the chroot too.
@falken @mhoye
here's the set as I know them
sudo mount --bind /dev /mnt/dev
sudo mount --bind /dev/pts /mnt/dev/pts
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys