LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 01-31-2013, 12:12 PM   #1
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0/14.1
Posts: 3,479

Rep: Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533
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 2.6.33.4 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.

Last edited by Woodsman; 01-31-2013 at 12:17 PM.
 
Old 01-31-2013, 12:23 PM   #2
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,750

Rep: Reputation: 462Reputation: 462Reputation: 462Reputation: 462Reputation: 462
"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.
 
Old 01-31-2013, 12:35 PM   #3
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0/14.1
Posts: 3,479

Original Poster
Rep: Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533
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?
 
1 members found this post helpful.
Old 01-31-2013, 12:50 PM   #4
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0/14.1
Posts: 3,479

Original Poster
Rep: Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533
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.
 
Old 01-31-2013, 01:34 PM   #5
Martinus2u
Member
 
Registered: Apr 2010
Distribution: Slackware
Posts: 343

Rep: Reputation: 56
Quote:
Originally Posted by Woodsman View Post
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.
 
Old 02-01-2013, 02:29 AM   #6
Petri Kaukasoina
Member
 
Registered: Mar 2007
Posts: 241

Rep: Reputation: 86
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.
 
Old 02-01-2013, 05:26 AM   #7
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,750

Rep: Reputation: 462Reputation: 462Reputation: 462Reputation: 462Reputation: 462
Very good:
Code:
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:
Code:
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:
/lib/modules/kernel-version
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.
 
Old 02-01-2013, 08:57 AM   #8
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0/14.1
Posts: 3,479

Original Poster
Rep: Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
run commands inside chroots entz Linux - General 2 05-13-2012 04:46 PM
Which ftp server software "chroots" users by default. uncle-c Linux - Newbie 7 08-09-2008 08:04 PM
backward compatibility in kernels + custom kernels + more queries mmp_3341 Linux - Kernel 1 04-12-2007 07:28 AM
which ftp server for virtual domains or multiple chroots Ratclaws Linux - Software 0 11-30-2005 01:22 PM
RH 8 kernels and their relation to 'stock' kernels psweetma Linux - Distributions 1 03-29-2003 10:46 PM


All times are GMT -5. The time now is 06:13 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration