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 ;) > Converting a perfectly working and efficiently running system to use > something like systemd just to have a chroot environment is overly complex > and convoluted. I agree; but as many of us are already using systemd, is good to know that the possibility exists. > These solutions often cause more issues then the problem it tried to solve. I was only offering options. The OP will use whatever he decides to use. Regards. -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
