Воссоздание установки Ubuntu для запуска неизвестного двоичного файла

У меня есть доступ к установке Ubuntu 16.04, которая может запускать определенный двоичный файл (это какая-то версия LPMud, скомпилированная с неизвестными параметрами), но я не могу запустить тот же двоичный файл на другой установке Ubuntu 16.04 - на второй system двоичный файл выходит из строя из-за ошибки сегментации.

Я не очень заинтересован в создании точной копии первой системы - я хотел бы знать, что именно нужно для запуска бинарника, чтобы я мог создать минимальную установку Ubuntu, которая может запускать бинарник.

Что было бы лучшим подходом? Я думал извлечь список установленных пакетов (используя apt list --installed) и каталог, переустановив пакеты во второй системе и скопировав /etcкаталог.

Я знаю, что есть много причин, по которым двоичный файл может segfault в другой системе, но я хотел бы попробовать некоторые менее интенсивные подходы к данным, прежде чем пытаться сузить среду от побитовой копии.

Это разумный подход? У кого-нибудь есть идея, как повысить шансы на успех?


Изменить - больше информации о двоичном файле:

      $ file driver
driver: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, stripped
      $ ldd driver
       statically linked
      $ gdb driver
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
"/mud/bin/driver": not in executable format: File format not recognized

Попытка отладки с 32-битной версией gdb приводит к аналогичным результатам:

      $ gdb driver
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
"/mud/bin/driver": not in executable format: File format not recognized
(gdb) show configuration
This GDB was configured as follows:
   configure --host=i686-linux-gnu --target=i686-linux-gnu
             --with-auto-load-dir=$debugdir:$datadir/auto-load
             --with-auto-load-safe-path=$debugdir:$datadir/auto-load
             --with-expat
             --with-gdb-datadir=/usr/share/gdb (relocatable)
             --with-jit-reader-dir=/usr/lib/gdb (relocatable)
             --without-libunwind-ia64
             --with-lzma
             --with-python=/usr (relocatable)
             --without-guile
             --with-separate-debug-dir=/usr/lib/debug (relocatable)
             --with-system-gdbinit=/etc/gdb/gdbinit
             --with-babeltrace

("Relocatable" means the directory can be moved with the GDB installation
tree, and GDB will still find it.)
(gdb) 
      $ strace -o ./log ./driver ; cat ./log
execve("./driver", ["./driver"], [/* 9 vars */]) = 0
brk(NULL)                               = 0x8952000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7f89000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
set_thread_area({entry_number:-1, base_addr:0xf7f89a80, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 (entry_number:12)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x4} ---
+++ killed by SIGSEGV (core dumped) +++

1 ответ

Сравнив хэши бинарника на первой и второй системе (используя md5sum), я обнаружил, что бинарник на второй системе был поврежден. Повторное копирование двоичного файла (и проверка идентичности хэшей) решило проблему.

Спасибо mestia , которые помогли в комментариях.

Другие вопросы по тегам