running autoconf in chrooted environments

[Peter Crady]

This may be a stupid question but is there a good way to run autoconf in a chrooted environment? From what I can tell the AS_UNAME function calls uname which gets information about the base kernel that is installed and not the kernel that is installed in the chrooted environment. Is there a function that does the same thing as AS_UNAME without actually using uname or is this something that has yet to be developed. It would be very helpful to have such functionality for building packages on build machines which are running different kernels than what is being run where you want to install the package. The specific case where I am encountering this is building lustre with SUSE's open build service.

Thanks

-Peter

[Eric Blake]

On 07/07/2016 02:15 PM, Peter Crady wrote:

[your mailer isn't configured to wrap long lines, which makes it harder
to read and reply]

Post by Peter Crady
This may be a stupid question but is there a good way to run autoconf

in a chrooted environment?

Do it the same way you run any other program - just run it. Remember,
if you have to modify autoconf to behave differently, then you would
have to modify every other program in the chroot environment in the same
manner; the whole point of autoconf is to probe the actual environment
it is running under. So if autoconf isn't getting the answers you want,
then it is your environment at fault, not autoconf.

And these days, chroot'd environments aren't as secure as cgroups,
containers or virtual machines, so you may want to look into those
technologies for better isolation of your test environment from your
host environment.

Post by Peter Crady
From what I can tell the AS_UNAME function calls uname which gets

information about the base kernel that is installed and not the kernel
that is installed in the chrooted environment.

If you're referring to uname(1) (the command line utility run by
AS_UNAME), then it is up to you whatever uname(1) binary you installed
into your chroot. If your uname(1) binary isn't returning the
information you want, then it's your fault for building an incomplete
chroot. And if your uname(1) in the chroot is returning the modified
information, then AS_UNAME will see that modified information, not the
base kernel information.

If you're referring to uname(2) (the system call, which is generally
what gets used under the hood by the uname(1) binary), then that depends
on whatever kernel is actually running the binary that makes the
syscall. If you are using merely chroot, then yeah, things are being
run by a single kernel (chroot isolates files, but not the kernel used
to run the files); which is where other technologies like containers
(such as docker) or virtual machines (such as qemu) indeed let you turn
on even more pieces to the point of completely running your test as if
it were a different machine and kernel than the host.

[Florian Weimer]

Post by Peter Crady
This may be a stupid question but is there a good way to run autoconf in a chrooted environment? From what I can tell the AS_UNAME function calls uname which gets information about the base kernel that is installed and not the kernel that is installed in the chrooted environment.

The kernel for the chroot environment is identical to the host kernel.

Post by Peter Crady
Is there a function that does the same thing as AS_UNAME without actually using uname

With UTS namespaces on Linux, it is possible to influence what uname
returns, within reason.

In general, it is not a good idea to lie too much about the nature of
the system because too much will break.

Florian