Re: [gentoo-user] What to put in chroot mtab

["Canek Peláez Valdés" <caneko@gmail.com>]

On Fri, Aug 1, 2014 at 4:44 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Fri, Aug 1, 2014 at 4:39 PM, J. Roeleveld <joost@antarean.org> wrote:
>> On 1 August 2014 23:33:05 CEST, "Canek Peláez Valdés" <caneko@gmail.com> wrote:
>>>On Fri, Aug 1, 2014 at 4:31 PM, Canek Peláez Valdés <caneko@gmail.com>
>>>wrote:
>>>> On Aug 1, 2014 3:46 PM, "J. Roeleveld" <joost@antarean.org> wrote:
>>>>>
>>>>> On 1 August 2014 15:28:01 CEST, Dale <rdalek1967@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