On Friday 01 August 2014 10:29:17 Canek Peláez Valdés wrote: > On Fri, Aug 1, 2014 at 10:21 AM, Peter Humphrey <pe...@prh.myzen.co.uk> wrote: > > On Friday 01 August 2014 10:00:40 Canek Peláez Valdés wrote: > >> ... just for completeness, systemd actually requires /etc/mtab as a > >> link to /proc/self/mounts, so don't be surprised if software in the > >> future in Linux just assumes that. > > > > Well, that seems to imply that you can't run a systemd chroot on a systemd > > or openrc host, no? > > If you want to "boot" a container with systemd-nspawn, then no, you > can't; you need mtab to be a symlink to /proc/self/mounts. If you > simply want to chroot to it, it doesn't matter; you will not be > running systemd anyway. > > > Because from inside the chroot, what /proc/self/mounts lists > > is inaccurate. > > In what sense is inaccurate? Inside my systemd-nspawn container: > > root@gentoo ~ # sort /etc/mtab | uniq > /run /var/run none rw,bind 0 0 > debugfs /sys/kernel/debug debugfs rw 0 0 > fusectl /sys/fs/fuse/connections fusectl rw 0 0 > hugetlbfs /dev/hugepages hugetlbfs rw 0 0 > mqueue /dev/mqueue mqueue rw 0 0 > tmpfs /tmp tmpfs rw,strictatime,mode=1777 0 0 > > That seems accurate to me. Sure, as Rich mentioned, there are > repetitions and other stuff, but nothing that a quick grep or sort > will not fix.
I only meant that things mounted outside the chroot are listed inside it, even though they can't be accessed from there. I've solved the problem for myself anyway, for now, by constructing a suitable mtab by hand from outside the chroot for use within it. > > I wouldn't like to be the one who has to write a new installation handbook > > for systemd-only systems! :) > > We'll need to rewrote the whole thing when we switch to systemd anyway. Indeed. -- Regards Peter
