On Fri, Aug 1, 2014 at 4:44 PM, Canek Peláez Valdés <can...@gmail.com> wrote: > On Fri, Aug 1, 2014 at 4:39 PM, J. Roeleveld <jo...@antarean.org> wrote: >> On 1 August 2014 23:33:05 CEST, "Canek Peláez Valdés" <can...@gmail.com> >> wrote: >>>On Fri, Aug 1, 2014 at 4:31 PM, Canek Peláez Valdés <can...@gmail.com> >>>wrote: >>>> On Aug 1, 2014 3:46 PM, "J. Roeleveld" <jo...@antarean.org> wrote: >>>>> >>>>> On 1 August 2014 15:28:01 CEST, Dale <rdalek1...@gmail.com> wrote: >>>>> >Peter Humphrey wrote: >>>>> >> On Friday 01 August 2014 14:07:08 I wrote: >>>>> >> >>>>> >>> I run a couple of chroots on this box to build packages for >>>other >>>>> >boxes on >>>>> >>> the LAN. So far, I haven't worked out what I should populate >>>>> >/etc/mtab with >>>>> >>> in each chroot. Is it enough to "grep ext4 /etc/mtab > >>>>> >>> /mnt/chroot/etc/mtab"? That catches all the physical partitions, >>>but >>>>> >I >>>>> >>> imagine I need to add some /proc, /sys and /dev entries as well, >>>but >>>>> >is >>>>> >>> there a simple formula for doing this? >>>>> >> I meant to add that one chroot is 32-bit and the other is 64. The >>>>> >host is an >>>>> >> i5 running openrc. >>>>> >> >>>>> > >>>>> >It has been a good while since I used this. So, make sure it makes >>>>> >sense to you before trying this. This may not work if something >>>has >>>>> >changed in the past several years. Use with caution if at all. >>>>> > >>>>> >This is a little script, if you want to call it that, that I used >>>to do >>>>> >mine. It also lists the command to use to do a 32 bit chroot from >>>a 64 >>>>> >bit rig. Here it is: >>>>> > >>>>> >root@fireball / # cat /root/xx.chroot-mount-32bit >>>>> > >>>>> > >>>>> >mount -o bind /dev /mnt/gentoo32/dev >>>>> >mount -o bind /dev/pts /mnt/gentoo32/dev/pts >>>>> >mount -o bind /dev/shm /mnt/gentoo32/dev/shm >>>>> >mount -o bind /proc /mnt/gentoo32/proc >>>>> >mount -o bind /proc/bus/usb /mnt/gentoo32/proc/bus/usb >>>>> >mount -o bind /sys /mnt/gentoo32/sys >>>>> >mkdir -p /mnt/gentoo32/usr/portage/ >>>>> >mount -o bind /usr/portage /mnt/gentoo32/usr/portage/ >>>>> > >>>>> > >>>>> >echo " mounting finished" >>>>> > >>>>> >echo "run linux32 chroot /mnt/gentoo32 /bin/bash next" >>>>> >root@fireball / # >>>>> > >>>>> > >>>>> >You may have different mount points at the very least so edit to >>>match >>>>> >what you have. Again, things could have changed and that no longer >>>>> >will >>>>> >work. It may not be a bad idea to let someone who has done this >>>more >>>>> >recently to give a thumbs up to that. >>>>> > >>>>> >That last command should be: >>>>> > >>>>> >linux32 chroot /mnt/gentoo32 /bin/bash >>>>> > >>>>> >Dale >>>>> > >>>>> >:-) :-) >>>>> >>>>> That script is too long :) >>>>> >>>>> cd /mnt/gentoo >>>>> mount -o rbind /dev dev >>>>> mount -o rbind /sys sys >>>>> mount -o rbind /proc proc >>>>> cp -L /etc/resolv.conf etc/resolv.conf >>>>> cd .. >>>>> chroot gentoo /bin/bash >>>>> >>>>> To undo: >>>>> cd /mnt/gentoo >>>>> umount -l proc sys dev >>>> >>>> That's still too long :) >>>> >>>> With systemd-nspawn, you only do: >>>> >>>> systemd-nspawn -D /mnt/gentoo >>>> >>>> Systemd takes care of /dev, /sys, etc. If the container has systemd >>>> installed, you can do >>>> >>>> systemd-nspawn -bD /mnt/gentoo >>>> >>>> and the services inside the container will be started like in a >>>regular boot >>>> (you'll need to set the root password for the container). >>>> >>>> Also, if you want to share the /usr/portage directory between host >>>and >>>> container, you only need to >>>> >>>> systemd-nspawn --bind=/usr/portage -bD /mnt/gentoo >>> >>>Oh, and I forgot: to stop the container, just log out if the container >>>runs OpenRC, or run systemctl poweroff if the container runs systemd. >>> >>>Regards. >> >> That script could easily be written in C and compiled and then called in a >> similar way as systemd-nspawn. > > And yet nobody has done it and got it included in most distributions. > >> What your command does is basically the same apart from doing something >> different from using chroots. > > True, but still it's shorter ;)
Sorry; I almost missed this. Actually systemd-nspawn does much more than chroot'ing and bind-mounting some dirs; it also runs the container in its own namespace. And it can add virtual networking a lot more stuff. See [1] for details. Regards. [1] http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
