-   Slackware (
-   -   Chroots and kernels (

Woodsman 01-31-2013 01:12 PM

Chroots and kernels
I have several partitions on my system for testing and compiling software against different Slackware releases. Rather than reboot, I've written a shell script that allows me to use those partitions in a chroot.

When I chroot into those partitions, how does the kernel affect compilations?

For example, when I am in Slackware 14 and I chroot into a Slackware 14 build partition, the kernels are the same. When I am in Slackware 14 and chroot into a Slackware 13.1 build partition, uname -a will show that the 3.2.29 kernel is being used, but the /usr/src/linux sources are those of the kernel that came packaged with 13.1. As a chroot is supposed to be isolated from the host system, do compilations that need the kernel sources use the chroot version or that of the host?

Thanks. :)

Note: I am interested in the effects of using a chroot, not with using a virtual machine. :)

gnashley 01-31-2013 01:23 PM

"do compilations that need the kernel sources use the chroot version or that of the host" it depends on how the software config decides which sources to use -whether by accessing /usr/src/linux or getting the running version. FO stuff that checks /usr/src you could symlink or 'mount --bind' the appropriate version of sources.

Woodsman 01-31-2013 01:35 PM

In my script I do bind a few things:

mount -t proc none ${CHROOT_MOUNT_POINT}/proc
mount -o bind /dev ${CHROOT_MOUNT_POINT}/dev
mount -o bind /dev/pts ${CHROOT_MOUNT_POINT}/dev/pts
mount -o bind /sys ${CHROOT_MOUNT_POINT}/sys
# $TMP is using tmpfs:
mount -o bind $TMP ${CHROOT_MOUNT_POINT}${TMP}

Are you saying I could bind the correct /usr/src/linux as well?

Woodsman 01-31-2013 01:50 PM

I'm asking because I've read that mixing architectures is a no-no. Because of that, thus far I've limited myself to chrooting like-for-like build partitions. I'm curious what happens when I chroot into a different build partition, such as chrooting into Slackware 13.1 from a Slackware 14.0 host.

I know virtual machines can avoid the discussion, but I've never been able to get my (VirtualBox) VMs to run as fast as a native environment. I don't know why that is, but compiling in a VM takes much longer than in a native environment.

Martinus2u 01-31-2013 02:34 PM


Originally Posted by Woodsman (Post 4881504)
do compilations that need the kernel sources use the chroot version or that of the host?

the chroot version, since the kernel sources in /usr/src and the kernel headers in /usr/include are part of the chroot jail. The latter ones are more important.

Petri Kaukasoina 02-01-2013 03:29 AM

You shouldn't need the kernel sources at all in your chroot environments because kernel sources are only used at the moment of building the kernel or kernel modules.

gnashley 02-01-2013 06:26 AM

Very good:

mount -t proc none ${CHROOT_MOUNT_POINT}/proc
mount -o bind /dev ${CHROOT_MOUNT_POINT}/dev
mount -o bind /dev/pts ${CHROOT_MOUNT_POINT}/dev/pts
mount -o bind /sys ${CHROOT_MOUNT_POINT}/sys
# $TMP is using tmpfs:
mount -o bind $TMP ${CHROOT_MOUNT_POINT}${TMP}

Yes, something like:

mount -o bind /path/to/alternate/sources ${CHROOT_MOUNT_POINT}/usr/src/linux
But, that will only work if the software -most likely a kernel module- determines the 'right' location that way. And/or, you may need to fix the link in:
There are a few lib or application sources which also refer to the kernel version or sources. My experience is that they don't all do the same thing, nor the same way. But at least, the cases are pretty rare. Course, you could always use kexec and simply reboot into the chroot! Probably a VM would be best when you need to do such jobs.

In the last few days I've working with fakechroot which seems to make things a lot easier. I use it on top of unionfs-fuse mounts, so I can control exactly what gets visible from where. I've been using unionfs-fuse (with real chroot) for years now in src2pkg with excellent results. Note that I'm talking about fakechroot, not fakeroot. My attempts with fakeroot have failed, so far.

I've also become aware in the last few days of the 'schroot' program -also from the folks at debian. schroot creates more secure chroots than any of the others. And, it lets you set up a configuration file for each chroot -so that you don't have to do everything manually. Each config can be aliased, so just 'schroot my-favorite-distro' creates and starts it.

One more thing about 'mount -o bind...' -submounts under the original root mount may or not be properly visible and usuable in the chroot, unless each one is bind'ed.

Woodsman 02-01-2013 09:57 AM

Interesting. Thanks. Thus far I've limited myself to chrooting partitions of the same Slackware release as the host. Works well for my nominal needs. I suppose eventually I'll test chrooting into a different release partition, build a set of packages, and then install the packages on a test system to see what breaks or acts goofy. :)

All times are GMT -5. The time now is 08:35 AM.