0

I have a Debian 9 installation with a Debian 6 chroot jail. I am using a proprietary application which up until recently worked fine in the jail. But when I run its newer versions, it crashes in libc. I tired creating a newer Debian jail (Debian 8) but it still crashes. If I run it on native Debian 8, it works. If I import my Debian 6/8 jail in Docker, it still works.

Does anybody have any idea why the application would crash in chroot but not when running naively or when the chroot directory is imported and ran in Docker?

3
  • 1
    Error messages?
    – Kusalananda
    Apr 9, 2018 at 12:14
  • more than simple error message, name of the application ?
    – Kiwy
    Apr 9, 2018 at 12:17
  • Intel compiler - error message is Segfault. When I set LD_DEBUG=bindings, I can see that it crashes in libc.so functions like memcopy for example. Apr 9, 2018 at 12:40

1 Answer 1

0

While the kernel folks try to avoid making incompatible changes to userspace ABIs, sometimes they do have to do so anyway (usually for security reasons), and then such issues may ensue. To avoid sudden breakage of userspace binaries, initially the old ABI will still be enabled, but after a while it gets disabled by default. At this point, such problems can occur.

To make things not fail, you have two options:

  • Install the old software in a VM (not a chroot) using the old kernel. This should always work
  • If your current kernel still has the feature that you need but doesn't have it enabled by default, you may be able to enable it for a while. Do note that doing so may reduce the security of your environment, however, so don't do it on security-critical environments.

For your specific issue, the most likely culprit is the vsyscall emulation, which is disabled by default in most recent distributions, but which can be enabled by specifying the kernel boot-time parameter vsyscall=emulate.

4
  • I booted the machine with vsyscall=emulate on the kernel line in GRUB but I still get a crash in the chroot jail. Apr 9, 2018 at 14:04
  • try vsyscall=native instead? Apr 9, 2018 at 14:32
  • vsyscall=native doesn't help either. Am I doing this the right way? I add this parameter on the linux line just after the quiet flag. Apr 10, 2018 at 6:14
  • That is the right way, yes. I gave you my usual culprits though, not sure anymore at this point Apr 12, 2018 at 12:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .