This is a discussion on RE: SSH, glibc, and Red Hat - openssh ; >> The only thing to watch for there is for kernel-related things since >> you're obviously running on the same kernel in the chroot. >Certainly. And a good thing to note. >> This was the case with the descriptor passing ...
>> The only thing to watch for there is for kernel-related things since
>> you're obviously running on the same kernel in the chroot.
>Certainly. And a good thing to note.
>> This was the case with the descriptor passing bugs in Linux 2.0
>> the Debian folk used chroots as you described. configure found that
>> descriptor passing worked fine (which it did, on the host's kernel)
>> even though it didn't on the target. They eventually added some code
>> to detect the buggy kernel versions at runtime.
>Yes that can be a problem. But that is almost the same problem as when
you compile something for the local machine and then boot to a different
>kernel on the same machine. Things that depend upon the kernel might
work differently. So what you say the Debian folks did, which was to
>the situation at runtime, sounds like a best case solution for things
that depend upon the kernel.
>I say almost the same problem because obviously most people don't lose
features when installing new kernels. But it does happen at times.
>I often boot into older kernels in order to test something or to try to
recreate some particular configuration. Fortunately there are few
>things that are sensitive to the kernel version.
All very good ideas, but in the essence of compatibility, I think I'll
just create a VM of the OS/kernel that's having the problems and just
add it to the build script.
Thanks for all the info, you guys have been immensely helpful.
openssh-unix-dev mailing list