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

[Canek Peláez Valdés]

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