Unable to reach network from chroot

Question

I have a complicated scenario, with most of the complicated parts working:

• SD card contains a Fedora 23 Raspberry Pi install on a LUKS/BTRFS filesystem.
• Fedora 23 x86-64 VM being used to manage the SD card install of Fedora for the RPi.
  • I can mount the SD card in my VM just fine and chroot into it using a static build of QEMU ARM, which was for some reason really difficult to obtain.

However, inside my chroot, I cannot access the network. When I've done similar things in Ubuntu/Debian, I can always access the network. I have disabled SELinux :(, and done a lot of bind-mounting to get things generally working, but I cannot get access to the network. I copied in /etc/sysconfig/network-scripts/ifcfg-enp0s3, and tried just about everything else I could think of.

My chroot setup looks something like this:

cryptsetup luksOpen /dev/sdXN picrypt
mount -t btrfs /dev/mapper/picrypt /mnt
mount -t proc none /mnt/proc
mount -t sysfs none /mnt/sys
mount --bind /dev /mnt/dev
mount --bind /dev/pts /mnt/dev/pts
mount --bind /run /mnt/run
chroot /mnt/

I've noticed that a lot more filesystems are mounted from my host's perspective, but I'm assuming that they're carried over automatically and just not appearing in the chroot for some reason. Here are the mounts my host knows about:

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=2013260k,nr_inodes=503315,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,seclabel,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime,seclabel)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/mapper/fedora-root on / type ext4 (rw,relatime,seclabel,data=ordered)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=22,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime,seclabel)
tmpfs on /tmp type tmpfs (rw,seclabel)
debugfs on /sys/kernel/debug type debugfs (rw,relatime,seclabel)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,seclabel)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
/dev/sda1 on /boot type ext4 (rw,relatime,seclabel,data=ordered)
/dev/mapper/fedora-home on /home type ext4 (rw,relatime,seclabel,data=ordered)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
tmpfs on /run/user/42 type tmpfs (rw,nosuid,nodev,relatime,seclabel,size=404748k,mode=700,uid=42,gid=42)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,seclabel,size=404748k,mode=700,uid=1000,gid=1000)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
/dev/sr0 on /run/media/naftuli/VBOXADDITIONS_5.0.20_106931 type iso9660 (ro,nosuid,nodev,relatime,uid=1000,gid=1000,iocharset=utf8,mode=0400,dmode=0500,uhelper=udisks2)
/dev/sdXN on /run/media/naftuli/PI-BOOT type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
tmpfs on /home/naftuli/tmp type tmpfs (rw,relatime,seclabel,mode=700,uid=1000,gid=1000)

My chroot knows about a lot less than this:

/dev/mapper/picrypt on / type btrfs (rw,relatime,seclabel,compress=lzo,space_cache,subvolid=5,subvol=/)
none on /proc type proc (rw,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=2013260k,nr_inodes=503315,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)
sysfs on /sys type sysfs (ro,relatime,seclabel)

In order to get a working chroot with networking support, do I really need to mount all of those /sys sub-filesystems into my chroot?

Solution 1

To set up networking for your chrooted session you need to copy the DNS configuration into the chroot environment :

cp /etc/resolv.conf /mnt/etc/resolv.conf

Or

ln -s /etc/resolv.conf /mnt/etc/resolv.conf

Solution 2

If you are behind a proxy then you also need to copy the proxy settings to chroot environment.

sudo cp /etc/apt/apt.conf /path/to/chroot/etc/apt/apt.conf

where /etc/apt/apt.conf may look like

Acquire::http::proxy "http://192.168.120.100:80/";
Acquire::https::proxy "https://192.168.120.100:80/";
Acquire::ftp::proxy "ftp://192.168.120.100:80/";

Comments

[Wouter Verhelst]

Can you give a bit more details on the failure mode? How exactly can you 'not access the network'?

[Naftuli Kay]

That's probably it. Forgot that part :-\

[Bas Wijnen]

The second option won't work. A symlink is just a file with the path of the target in it (and marked as "this is a symlink"). It doesn't give the process in the chroot permission to access that file. And because it is not within the chroot tree, it will be a broken symlink from the chroot.