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?

  • 1
    Error messages? – Kusalananda Apr 9 '18 at 12:14
  • more than simple error message, name of the application ? – Kiwy Apr 9 '18 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. – RegedUser00x Apr 9 '18 at 12:40
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.

  • I booted the machine with vsyscall=emulate on the kernel line in GRUB but I still get a crash in the chroot jail. – RegedUser00x Apr 9 '18 at 14:04
  • try vsyscall=native instead? – Wouter Verhelst Apr 9 '18 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. – RegedUser00x Apr 10 '18 at 6:14
  • That is the right way, yes. I gave you my usual culprits though, not sure anymore at this point – Wouter Verhelst Apr 12 '18 at 12:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.