Не удается запустить бинарный файл ошибка формата выполняемого файла

Обновлено: 06.01.2025

Хотя это не должно происходить при использовании официальных репозиториев apt-get, если вы загружаете программное обеспечение из Интернета и запускаете его, есть вероятность, что вы увидите страшные bash: ./nameOfProgram: невозможно выполнить двоичный файл: ошибка формата Exec. Эта ошибка, за которой обычно следует bash: ./nameOfProgram.sh: В доступе отказано или что-то в этом роде означает, что Ubuntu не может правильно взаимодействовать с загруженным вами двоичным файлом. Это потому, что, хотя это, по-видимому, допустимый двоичный файл Linux, он разработан для набора микросхем, отличного от того, который поддерживает ваше ядро.

Способ 1: использование команды arch

Если вы не знакомы с типом микропроцессора, который вы установили на своем компьютере, то сначала вы захотите использовать команду arch из командной строки. После выполнения этой команды вы увидите только одну строку вывода. Во многих случаях вы увидите i686, что означает, что вы используете 32-разрядный процессор и, следовательно, не можете запускать двоичные файлы x86_64. Если вместо этого вы видите amd64 или что-то подобное, то вы работаете на процессоре x86_64 и, по крайней мере, теоретически должны быть в состоянии запустить большинство 32-битных и 64-битных двоичных файлов. В отличие от Microsoft Windows, Ubuntu Linux фактически содержит надлежащие инструменты, позволяющие пользователям 644-битных наборов микросхем запускать 16-битные программы Windows в своей операционной системе во многих случаях.

Вы можете увидеть некоторые другие типы вывода, которые могут еще больше ограничить ваши возможности, когда дело доходит до запуска программного обеспечения. Ubuntu долгое время поддерживала архитектуру PowerPC, которая встречается на некоторых рабочих станциях, а также на многих компьютерах Classic Macintosh и более старых машинах OS X Macintosh. На самом деле вы все еще можете найти репозитории Ubuntu для этих архитектур, хотя сегодня они получают небольшую поддержку. Однако в этом случае вы, скорее всего, не сможете запустить много бинарных файлов Linux, которые вы загружаете из Интернета, за пределами официальных репозиториев. Это не означает, что Ubuntu не работает на этих машинах, хотя вы, возможно, захотите взглянуть на более легкий дистрибутив Lubuntu.

Способ 2: с помощью команды файла

Команда file определяет, какие файлы содержатся, и она обычно очень точная. Попробуйте определить нужный файл, набрав file nameOfProgram чтобы увидеть, если вы получите ELF 32-бит или ELF 64-бит в качестве вывода. Если он говорит вам, что это 64-битный двоичный файл ELF, и вы получили i686 в качестве вывода из команды arch, то вы не сможете разумно запустить его на своем компьютере. Если вы используете 64-битный микропроцессор, работающий под управлением 32-битной Ubuntu, то вы можете технически переустановить операционную систему, хотя это немного экстремальный шаг для запуска одной программы.

Существует также очень реальная возможность, хотя и незначительная, что вы можете вместо этого наткнуться на двоичный файл, который при попытке запустить его выдает ненужные символы в терминал, даже если вы запускаете сканирование вредоносных программ на нем. Эти символы обычно принимают форму блоков в форме ромба или, альтернативно, прямоугольных кубов с числовыми значениями в них. Некоторые компьютерные ученые называют последнее тофу и представляют значения символов Unicode, которые установленные вами шрифты не смогут отображать. Если терминал отображает их таким образом, то вы можете быть уверены, что это не ошибка шрифта или что-либо, имеющее отношение к вредоносному ПО. Скорее, это просто потому, что скомпилированный код операции микропроцессора внутри двоичного кода настолько чужд вашей системе, что он не знает, как интерпретировать часть кода.

В операционной системе Linux при запуске скаченного файла, либо при запуске самостоятельно скомпилированного файла вы можете столкнуться с ошибкой:

Если у вас англоязычная локаль, то ошибка будет примерно такой:

В самой ошибке вместо /путь/до/файла и ./program будет указан путь до файла программы, который вы хотите запустить.

Причинами данной ошибки могут быть:

попытка запустить 64-битный файл на 32-битной системе
файл скомпилирован для другой архитектуры (например, для ARM, а вы пытаетесь запустить его на ПК)
вы пытаетесь выполнить не исполнимый файл, а ссылку
файл размещён в совместной (shared) папке

Чтобы получить информацию о файле, который вы пытаетесь запустить, можно использовать утилиту file, после которой укажите путь до файла:

Здесь мы видим, что файл предназначен для 64-битной системы, об этом говорит запись 64-bit, для процессора с архитектурой x86-64.

Ещё один пример:

Этот файл для 32-битных систем, для процессора с архитектурой ARM EABI4.

Если вы не знаете, какой битности ваша система, то выполните команду:

Для 64-битных систем будет выведено x86_64, а для 32-битных – x86.

О разрядности дистрибутивов Linux и о программ

На компьютер с 32-битным процессором вы можете установить только 32-битную операционную систему и в ней запускать только 32-битные программы.

На компьютер с 64-битным процессором вы можете установить как 64-битную ОС, так и 32-битный Linux. В случае, если вы установили 64-битный дистрибутив Linux, то в нём вы можете запускать и 64-битные программы и 32-битные. А если вы установили 32-битный дистрибутив, то в нём возможно запускать только 32-битные программы.

Итак, если у вас 32-битная система, а файл для 64-битной системы или даже для ARM архитектуры, то у вас следующие варианты:

скачать файл подходящей для вас битности и архитектуры
если вы самостоятельно компилировали файл из исходного кода, то заново скомпилируйте для процессора вашей архитектуры

Запуск ARM файлов в Linux

Часто можно запустить исполнимые образы ARM на amd64 системах если установить пакеты binfmt-support, qemu, и qemu-user-static:

Заключение

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

Пытаешься запустить 64 битный JDK на 32 битном дистрибутиве?

Ну и выложи еще

buddhist ★★★★★ ( 04.08.18 12:28:38 )
Последнее исправление: buddhist 04.08.18 12:29:23 (всего исправлений: 1)

миллиардный раз объясняю. Пакеты java в дистрибутивах создают обычно шизики.

способ установки человека, котоырй не хочет потом бегать с голой жопой:

1) Качаем JDK с официального сайта. JDK, а не JRE! Распаковываем в папочку.

2) Прописываем переменную export $JAVA_HOME=, указывающую на то место, куда распаковали.

3) Добавляем export PATH=$JAVA_HOME/bin:$PATH

Если джава планируется запускаться от пользователя - то распаковывать в его домашнюю папку и прописывать экспорты в

Если джава планируется запускаться системно - то распаковываем куда-нибудь в корень (например, в /opt/jdk), переменные прописываем в /etc/profile.

Зачем заниматься этим рукоблудием, когда есть официальный rpm-пакет?

JDK 8 же от Оракла будет в EOL для незаплативших очень очень скоро. JDK 11 еще даже не зарелизилось. Бета-версии 9 и 10 не предлагать. Какой из сайтов теперь официальным для JDK 8 (такой себе жабааналог Python 2.7) будет?

Пакетики восьмерки в шапке/бубунте по крайней мере еще долго будут поддерживать.

потому что описанное выше решение работает в 146% случаев

146 лет в арче ставлю из репы, все работает на ура.

Arch Linux не предназначен для работы, поэтому эта делёжка опытом не актуальна. Но я как-то был на компьютерных курсах, где изучалась одна программа на Java. Преподаватель был слабый - знал ненамного больше, чем рассказывал. и излагал так, что я ничего бы не понял, если бы и без того это не знал. Неудивительно, что он поставил на учебные компьютеры Arch Linux, и совсем не удивительно, что программа зависала. Я проверил её в Debian и Fedora - как я и ожидал, работала нормально. JDK может понадобиться до двух версий- 10 и (для старых программ) 8. Сам он бывает двух видов - OpenJDK (этот входит в хранилища) и Oracle JDK (этот списывается с сайта Oracle). Иногда энтузиасты предоставляют свои PPA архивы со стандартным JDK.Но это не основной способ установки.В общем, стандартный JDK от Oracle лучше тем, что больше проверен, и производители некоторых важных программ тестируют их на совместимость с ним. Но может устроить и OpenJDK. У автора вопроса проблема в том, что он поставил JDK неправильно. Из его описания не видно, как. Может, архив битый или он запускает 64 битный JDK в 32 битной ОС. В общем, убрать этот ущербный JDK и установить заново, ознакомившись с инструкцией, как это делать.

именно так ставится оракловая java из ppa на дебиан-бубунту.

Судя по всему у тс проблемы как раз от того что он руками её ставил. Ну или рач какой-нить.

новые сборки джавы будут раз в полгода. Рекомендую обновляться раз в полгода. Это новая политика Партии, от нее никуда не деться. Все кто будут пытаться делать вид, что ничего не произошло - будут жутко мучиться, и решения этому нет никакого. Комьюнити _специально_ позаботилось, чтобы этому не было никакого решения.

Пакетики восьмерки в шапке/бубунте по крайней мере еще долго будут поддерживать.

Я лично остаюсь на восьмёрке и просто не буду обновляться, если не найдётся серьёзный вендор. Мне нужна 32-битная джава, которая нормально работает на XP. Про обновляться раз в полгода это вообще несерьёзно.

Если джава планируется запускаться от пользователя - то распаковывать в его домашнюю папку и прописывать экспорты в

/.bashrc)

За такой способ прописывания переменных в приличном обществе бьют по лицу. Особенно, если это сервак. Нормальные люди пишут wrapper script и кладут его в /usr/local/bin или в $HOME/.local/bin.

да неважно как $PATH записывать. Важно чтобы все зависело от тебя, а не от админа сервера (который может и не дать тебе права на bin), и не от создателя дистрибутива

более лучший вариант - Docker. Стараюсь теперь совершенно все запускать в нем.

Пакетики восьмерки в шапке/бубунте по крайней мере еще долго будут поддерживать.

Вроде October 2020 для jdk8 это не очень уж и долго, всего на полтора года дольше чем Oracle Java 8. Но внимание, тынц на предыдущую версию этой страницы:

Срок поддержки для jdk7 продлили на 2 года, а для jdk8 оставили таким же, что есть очень нелогично, так как переход jdk7 -> jdk8 гораздо менее болезненный чем jdk8 -> jdk11. Отсюда логично предположить, что поддержку jdk8 тоже продлят года на 2. Шапка продает саппорт на ЖиБосс, и покупатели очевидно будут хотеть поддержку jdk8 на все время пока ЖиБосс не научится в jdk11 и пока все бузинесс-критикал приложения на jdk11 переведут (т.е. - никогда).

Пакетики в CentOS 7 == пакетики в шапке 7 (тупая пересборка). Пакетики в бубунте - ну очень похожи на пакетики из шапки помимо именования.

Рекомендую обновляться раз в полгода.

Это новая политика Партии, от нее никуда не деться. Все кто будут пытаться делать вид, что ничего не произошло - будут жутко мучиться, и решения этому нет никакого.

И это будет финальный гвоздь в крышку гроба Java. Печально, что Партия решила воссоздать в экосистеме такой же отвратный бардак, который сегодня царит, например, в Web-разработке.

Я лично остаюсь на восьмёрке и просто не буду обновляться

+1, как и руководства многих разумных ынтерпрайзных предприятий.

Про обновляться раз в полгода это вообще несерьёзно.

Мне нужна 32-битная джава, которая нормально работает на XP

Из них AdoptOpenJDK - самое официальное место, там правда вроде нет сейчас 32-битных сборок, но они известные слоупоки и вполне могут добавить 32-бит позднее.

в отличие от бардака в веб-разработке, тут релизы релизят настоящие волшебники, и каких-то особых проблем с обновлениями быть не должно.

никаких left-pad, если ты об этом

На компьютере, с которого сейчас пишу, JDK 10.0.1 apt-get'ом нормально установился.

А вот Eclipse Photon я ставил в /opt ручками.

PS. Еще ANT_HOME и M2_HOME тоже желательно указать.

Bioreactor ★★★★★ ( 06.08.18 21:28:32 )
Последнее исправление: Bioreactor 06.08.18 21:29:21 (всего исправлений: 1)

А есть Oracle и IBM.

Бардак - это LAMP - пых-пых, гвидопых и прочие кустарные поделия от кульхацкеров-одиночек.

Bioreactor ★★★★★ ( 06.08.18 21:37:05 )
Последнее исправление: Bioreactor 06.08.18 21:38:53 (всего исправлений: 1)

Это ты сейчас на каком языке пишешь?

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

там везде есть раздел Features, где приведен список JEP, в которых четко и конкретно, грамотными людьми, описано - что это такое, зачем нужно, как посмотреть

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

А в 10 и 11 там по сути, всякая минорщина. Не факт что на ЛОРе бы про такое разрешили писать мини-новость.

Нет в этом ничего жуткого, необычного. Чего-то такого, что разработчики на почти любых других технологиях не видели бы при самых обычных обновлениях

Как обычно, истерят в основном белки-истерички

stevejobs ★★★★☆ ( 07.08.18 14:40:47 )
Последнее исправление: stevejobs 07.08.18 14:41:47 (всего исправлений: 1)

Ну, а как вообще, сообщество/опенсорс, пишет под 9-10-11 или всё медленно движется?

Если ты об backward compatibility, то все основные вещи давным-давно совместимы вплоть до 11. Специально собиралась статистика, были какие-то тэги в твиттере, но это уже не актуально. Всё просто работает. За исключением вещей вроде JavaEE и Nashorn.js, которых просто выбросили из JDK на мороз.

Основной дизастер был за пару месяцев до и после выхода 9 в прошлом году. После этого уже не было ченжей, чтобы что-то там поломалось. Ченжи вроде добавления Shenandoah GC приносят новые крутые фичи и не способны что-то поломать на уровне пользовательского API

Если ты о версии кода, то понятия не имею. Скорей всего, внедрение идет только на уровне совсем новых с смелых проектов, в том же Spring. Проблема в том, что forward compatibility нет, собранное под 11 не запустится на 8, и соответственно возникает вопрос - готовы ли проекты потерять всякий совсем кровавый ынтерпрайз из своих клиентов. Думаю что до выхода JDK 11 и сбора реальной статистики - сколько больших компаний перекатились с 8 на 11 - охотников будет немного.

stevejobs ★★★★☆ ( 07.08.18 21:42:54 )
Последнее исправление: stevejobs 07.08.18 21:50:03 (всего исправлений: 5)

Есть и не мини-книжки. Наиболее важное нововведение в Java 9 - система модулей. Надо ознакомиться с ней, чтобы решить, как использовать в своих разработках. Остальное больше относится к удобству. Но JDK 9, хоть он и новый, не имеет особого смысла использовать ввиду наличия JDK 10. В котором однако изменения в самом языке незначительны. Так что изучать нововведения можно по литературе о JDK 9, а пользоваться JDK 10. JDK 8 оставить для программ, которые ещё не проверены на совместимость с JDK 10.

Я пытаюсь запустить программу, но ошибка происходит так:

Результатом file program было:

Я использую Ubuntu 14.04.2 (amd64) с VMware. Я тоже пробовал с Ubuntu i386, но результат был таким же.

Это исполняемый файл ARM, т. Е. Вы загрузили неверный формат исполняемого файла или скомпилировали для неправильной платформы. Вы должны получить правильный исполняемый файл или перекомпилировать.

Вы пытаетесь запустить исполняемый файл, скомпилированный для архитектуры ARM на архитектуре x86-64, что очень похоже на запрос вашего процессора, который говорит только по-английски, указывать направление на китайском.

Если вам нужно запустить этот исполняемый файл, у вас есть два варианта:

Получить версию исполняемого файла x86-64 (любым способом; если вам не удается получить версию исполняемого файла x86-64, но вы можете получить его исходный код, вы можете попытаться перекомпилировать его на виртуальной машине );

Установите Ubuntu Server for ARM вместо Ubuntu 14.04.2 (amd64). Для этого требуется либо физическая машина, работающая на архитектуре ARM, либо программное обеспечение для виртуализации, которое может эмулировать ее.

Это также может произойти, если вы попытаетесь запустить исполняемый файл x86-64 на 32-разрядной платформе.

В одном конкретном случае я скачал код Visual Studio и попытался запустить его на своей установке Ubuntu, но я не понял, что я установил 32-битную Ubuntu в эту виртуальную машину. Я получил эту ошибку, но после загрузки 32-разрядной версии, он работал без проблем.

Часто можно запустить исполняемый образ ARM в системе amd64, если вы установите пакеты binfmt-support , qemu и qemu-user-static :

qemu затем выполнит эмуляцию syscall при запуске исполняемого файла. Это работает для большинства двоичных файлов ARM, но есть некоторые, которые могут работать неправильно.

sudo apt-get install binfmt-support qemu qemu-user-static

Такая ошибка может возникнуть, если выполняются все следующие условия:

Исполняемый файл - это не файл, а ссылка
Вы запускаете запустить его внутри ВМ
Файл находится в общей папке
Ваш хост - Windows.

Если вы получили этот файл, скажем, в архиве - попробуйте распаковать его внутри виртуальной машины, в какой-то каталог внутри виртуального диска, а не в папку, сопоставленную, например, с жестким диском хост-машины. /myNewDir/

Это очень полезно. Для меня я создал ярлык (ссылку) на этот исполняемый файл, а затем вызвал ярлык ошибки.

Вы должны скомпилировать свой файл, используя соответствующую архитектуру ЦП (например, x86), и скопировать файл .exe на свой компьютер с Linux. Затем вы можете установить mono на вашем Linux-компьютере и выполнить следующую команду:

Если java в системе установлено более одного, это может произойти и не будет установлено по умолчанию. На Ubuntu14.04 LTS я мог решить ее, выполнив следующее и выбрав java нужное.

Я выбираю 2 и устанавливаю openjdk-8 по умолчанию. Который не показал Exec format error .

Это также может произойти, если двоичный файл использует реализацию libc, которая не является libc, например, musl. В эти дни эта конкретная проблема, скорее всего, встречается при попытке запуска двоичного файла с libc в контейнере Docker с изображением, основанным на alpine. Ничто не может быть сделано с самим двоичным файлом для поддержки обеих сред, потому что реализация libc всегда должна быть статически связана, то есть встроена непосредственно в двоичный файл, по причинам.

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

Есть ли способ выполнить файл с Java в Bash Terminal?

Я пытаюсь выполнить файл Minecraft.jar.

Синтаксис . может использоваться только для запуска сценариев оболочки (sourcing).

Вам нужно будет использовать команду java для запуска файла .jar: [ ! d1] java -jar Minecraft.jar

Синтаксис . может использоваться только для запуска сценариев оболочки (sourcing).

Вам нужно будет использовать команду java для запуска файла .jar: [ ! d1] java -jar Minecraft.jar

Вы также можете сделать приятную запись для приложения в Unity. выполните следующие команды:

В появившемся окне скопируйте и вставьте следующее:

[Desktop Entry] Type=Application Name=Minecraft Comment=Click here to play Minecraft Exec=java -jar /path/to/minecraft.jar Icon=/path/to/minecraft/icon.jpg Terminal=false Categories=Game;

Возможно, вам придется выйти из системы и вернуться в последствия. :) Также вам нужно искать в Интернете красивый значок Minecraft, так как они не обеспечивают загрузку ..

Откройте командную строку с помощью CTRL + ALT + T Перейдите в каталог файлов .jar. Если ваша версия / аромат Ubuntu поддерживает его, вы можете щелкнуть правой кнопкой мыши по каталогу файла «.jar» и нажать «Открыть в терминале» Введите следующую команду: java -jar jarfilename.jar

Таким образом, ваш " .jar "будет выполнен.

Установите jarwrapper. После этого (и добавив исполняемый бит) вы можете запустить файл jar, просто введя имя jarfile.

sudo apt-get install jarwrapper

Это работает, используя binfmt, чтобы добавить поддержку нового двоичного формата в ядро.

Linux вполне способен запускать внешний двоичный файл, например JAR-файл. Так работает вино, например. Для запуска JAR-файлов в качестве исполняемого файла выполните следующие действия в консоли

sudo apt-get install binfmt-support

Cd в ваш JAR-файл и измените его на исполняемый файл (вы также можете сделать это с помощью свойств файла в Nautilus)

chmod a+rx myjar.jar

Запустите файл jar так же, как если бы это был любой другой исполняемый файл или сценарий оболочки

, если вы хотите установить свою банку с конкретной версией java. Укажите каталог java также

/scratch/app/product/Software/jdk1.8.0_112/bin/java -jar /path-to-jar/Minecraft.jar

Если это исполняемый jar, то

java -jar Minecraft.jar

Не все jar-архивы содержат исполняемый класс, объявленный для запуска в файле манифеста, но если есть, это будет работать. [ ! d1]

Btw: Вы не запускаете большинство программ из оболочки с точкой. Точка - это ярлык для source, и он работает только в bash и некоторых других оболочках, чтобы включить скрипт в область текущего сеанса.

Скомпилированный двоичный xybin просто начинается с его имени, если он находится в пути:

или, с его абсолютным путем:

или с его относительным путем:

или если вы попали в каталог файла с этим относительным путем:

Файл должен быть (см. chmod). Все вышесказанное верно и для shellscripts, но у них часто есть расширение .sh, и вы можете запустить shellscript, вызвав интерпретатор, и тогда его не нужно отмечать как исполняемый файл:

Если вы не хотите запускать новый bash, вы можете использовать источник, и вы это делаете, чтобы использовать определения функций, псевдонимы и параметры переменных.

Читайте также: