5

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?

  • 2
    Can you give a bit more details on the failure mode? How exactly can you 'not access the network'? – Wouter Verhelst May 2 '16 at 6:08
13

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
  • 1
    That's probably it. Forgot that part :-\ – Naftuli Kay May 2 '16 at 15:23
1

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/";
0

Working on Ubuntu 18.04.1 today I have to use:

sudo rsync -avh --devices --specials /run/systemd/resolve /target/run/systemd 

in order to have a working net connection in chroot.

You have to verify if the resolve directory is at the same spot on the chroot source and target, as they may change with the evolving update process. In my case, with some weeks of updates missing :

Source: VERSION="18.04.2 LTS (Bionic Beaver)"

Target: VERSION="18.04.1 LTS (Bionic Beaver)"

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.