[gentoo-user] What to put in chroot mtab

[Peter Humphrey]

Hello list,

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?

--
Regards
Peter

[Peter Humphrey]

I meant to add that one chroot is 32-bit and the other is 64. The host is an
i5 running openrc.

--
Regards
Peter

[Dale]

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

:-) :-)

[Rich Freeman]

ln -sf /proc/self/mounts > /etc/mtab

Problem solved, mostly. I still get some garbage in mount output in
containers, but this seems to be the way everything is going.

Rich

[Peter Humphrey]

Thanks for your script, Dale, but I already have something like it in
/etc/init.d/<chroot>. It's what to put in the chroot's mtab I was asking
about.

Thanks for your suggestion too, Rich. It gives an even longer list of mounts
than the host's mtab.

I now realise that I haven't thought this through properly. I want the
chroot's mtab to contain references to all the things it can see, and only
those, modified if necessary to strip off the path to the chroot itself.
Listing all the ext4 file-systems outside the chroot (which it can't see) is
stupid.

Looks like a manual setup is needed.

--
Regards
Peter

[Rich Freeman]

On Fri, Aug 1, 2014 at 11:00 AM, Canek Peláez Valdés <can...@gmail.com> wrote:
> And 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.

Part of the reason for this is namespace support. As namespaces
become more popular the concept of a global list of mounts goes away,
because every process on the system has its own view of the virtual
filesystem.

Chroots are just a very primitive form of file namespaces when you
think about it.

Rich

[Canek Peláez Valdés]

As Rich already pointed out, just make /etc/mtab a symlink from
/proc/self/mounts. If there is more mount points there than the ones
you need, grep -v'd them.

And 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.

Saludos.
--
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

[Peter Humphrey]

That's an interesting thought. So far I've ignored namespaces, but I can see
some reading being needed soon.

--
Regards
Peter

[Peter Humphrey]

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? Because from inside the chroot, what /proc/self/mounts lists
is inaccurate.

I wouldn't like to be the one who has to write a new installation handbook for
systemd-only systems! :)

--
Regards
Peter

[Canek Peláez Valdés]

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 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.

Regards.

[Peter Humphrey]

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

[Neil Bothwick]

Do you need anything in mtab in the chroot? I've been using chroots to
build packages for slower machines for years and /etc/mtab has always
been empty or non-existent, with no problems. df gets the hump when run
inside the chroot, but the package building works fine.


--
Neil Bothwick

Every morning is the dawn of a new error...

[J. Roeleveld]

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

If you need a 32bit chroot, put linux32 before the chroot like Dale mentioned.

--
Joost
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[J. Roeleveld]

You don't need anything in mtab. I've been building packages for multiple machines for years. Never had any issues using them to update the rest.

Only have issues with fetch restricted files blocking the use of a fully automated system.

[Canek Peláez Valdés]

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

Regards.

--

Canek

[Canek Peláez Valdés]

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.

[Canek Peláez Valdés]

On Fri, Aug 1, 2014 at 4:39 PM, J. Roeleveld <jo...@antarean.org> wrote:

> 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.

[J. Roeleveld]

That script could easily be written in C and compiled and then called in a similar way as systemd-nspawn.

What your command does is basically the same apart from doing something different from using chroots.

Converting a perfectly working and efficiently running system to use something like systemd just to have a chroot environment is overly complex and convoluted.

These solutions often cause more issues then the problem it tried to solve.

[Canek Peláez Valdés]

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

[Dale]

Well, at the time, I made it do what I was having to do by hand
following the guide. I just got tired of typing it all in so I made a
little scripty thingy. It worked for me. As I mentioned before, it was
a long time ago so things may have changed.

Dale

:-) :-)

[J. Roeleveld]

Because there is no need.
If all you need is merge a few lines into a single command, puttincg it into a shell script is quicker and far easier to maintain.

>> What your command does is basically the same apart from doing
>something different from using chroots.
>
>True, but still it's shorter ;)

chroot.sh is only 9 characters.
Naming the script 'a' would be even shorter.

[J. Roeleveld]

On 1 August 2014 23:46:00 CEST, "Canek Peláez Valdés" <can...@gmail.com> wrote:
>
>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

Sounds like overkill just to create a chroot to build packages.

Is usefull if you want to isolate services into seperate containers. In which case this is just another system partitioning tool merged into the init system.

[Peter Humphrey]

On Friday 01 August 2014 16:44:11 Canek Peláez Valdés wrote:

> I was only offering options. The OP will use whatever he decides to use.

All interesting stuff. Personally, I'm not ready to go for systemd, as the
openrc system I have works well for me and I understand it (mostly).

I settled on an init script to set up the chroot, with a suitable mtab ready
to be copied in. For anyone who's interested, this is the init:

start() {
ebegin "Mounting 32-bit chroot dirs"
mount -t proc /proc /mnt/atom/proc
mount --rbind /dev /mnt/atom/dev
mount --rbind /sys /mnt/atom/sys
mount -t nfs 192.168.0.2:/usr/portage/packages /mnt/atom/usr/portage/packages
cp /root/mtab.atom /mnt/atom/etc/mtab
eend $? "An error occurred while attempting to mount 32-bit chroot directories"
}

stop() {
ebegin "Unmounting 32-bit chroot dirs"
rm /mnt/atom/etc/mtab
umount -f /mnt/atom/dev/mqueue
umount -f /mnt/atom/dev/pts
umount -f /mnt/atom/dev/shm
umount -f /mnt/atom/dev
umount -f /mnt/atom/proc
umount -f /mnt/atom/sys/fs/cgroup/openrc
umount -f /mnt/atom/sys/fs/cgroup/cpuset
umount -f /mnt/atom/sys/fs/cgroup/cpu
umount -f /mnt/atom/sys/fs/cgroup/cpuacct
umount -f /mnt/atom/sys/fs/cgroup/freezer
umount -f /mnt/atom/sys/fs/cgroup
umount -f /mnt/atom/sys/kernel/debug
umount -f /mnt/atom/sys
umount -f /mnt/atom/usr/portage/packages
eend $? "An error occurred while attempting to unmount 32-bit chroot directories"
}

(I've omitted several sleeps from the /stop/ procedure.) If I left out any of
the lower-level umounts, the ones above it would fail.

# cat /root/mtab.atom
devtmpfs /dev devtmpfs rw,relatime,size=8201684k,nr_inodes=2050421,mode=755 0 0
/sys /sys none rw,bind,rbind 0 0
/dev /dev none rw,bind,rbind 0 0
proc /proc proc rw,relatime 0 0
tmpfs /run tmpfs rw,nosuid,nodev,relatime,size=1640604k,mode=755 0
0
mqueue /dev/mqueue mqueue rw,nosuid,nodev,noexec,relatime 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620 0 0
shm /dev/shm tmpfs rw,nosuid,nodev,relatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,nosuid,nodev,noexec,relatime 0 0
cgroup_root /sys/fs/cgroup tmpfs rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755 0 0
openrc /sys/fs/cgroup/openrc cgroup rw,nosuid,nodev,noexec,relatime,release_agent=/lib64/rc/sh/cgroup-release-agent.sh,name=openrc 0 0
cpuset /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cpu /sys/fs/cgroup/cpu cgroup rw,nosuid,nodev,noexec,relatime,cpu 0 0
cpuacct /sys/fs/cgroup/cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpuacct 0 0
freezer /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
/dev/mapper/vg7-atom / ext4 rw,relatime,commit=0 1 2

That probably has a lot more stuff in it than I need; I just removed the
things I certainly didn't need from a copy of the host mtab.

There's a similar init script and mtab for the other chroot.

I've no doubt all you systemd people will throw up your hands in dismay at the
work involved in setting that up. It didn't take long, really.

--
Regards
Peter

[Peter Humphrey]

On Friday 01 August 2014 20:32:54 Neil Bothwick wrote:
> On Fri, 01 Aug 2014 14:07:08 +0100, Peter Humphrey 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?
>
> Do you need anything in mtab in the chroot?

Only while keeping the chroot clean so that it matches the target.
Specifically, locale-purge, which is run in a clean-up script from time to
time.

> I've been using chroots to build packages for slower machines for years

Yes, I know - that's where I got the idea ;)

> and /etc/mtab has always been empty or non-existent, with no problems. df
> gets the hump when run inside the chroot, but the package building works
> fine.

--

Regards
Peter

[Rich Freeman]

The handbook now mentions the systemd install guide.

It isn't an entirely clean thing. Basically you install systemd, and
then you're referring to both. For anything that has a systemd and
openrc version (setting timezone, locale, etc), you do it the systemd
way. Stuff like configuring grub is generic.

--
Rich