Не могли бы вы помочь мне решить эту проблему.
Я «случайно» rpm -e библиотеки glibc.x86_64 сделал свой VPS непригодным для использования, так как все команды выдают одну из следующих ошибок:
[root@panel lib64]# yum
bash: /usr/bin/yum: /usr/bin/python: bad interpreter: No such file or directory
[root@panel lib64]# ls
bash: /bin/ls: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory
Если что-либо из следующего может помочь:
1) Я все еще подключен к оболочке
2) Я не могу загрузиться до восстановления, так как это удаленный VPS
3) все еще установлен i686 glibc
4) В моем домашнем каталоге есть файл .rpm версии x86_64.
5) Есть /lib/ld-linux.so.2, могу ли я каким-то образом указать системе на его использование?
6) У меня есть /opt/glibc-2.14/lib/ld-linux-x86-64.so.2, и я могу выполнять команды с префиксом, но самые важные из них, такие как rpm2cpio или wget, вызывают ошибки общих объектов.
Могу ли я решить эту проблему с помощью статических команд или добавления какой-либо другой библиотеки в путь или любым другим способом?
Спасибо всем заранее.
Я бы посоветовал скачать glibc x86_64.rpm пакет через wget, а затем установите его с помощью об / мин команды.
Я думаю, вы можете собрать исходный код для glibc.x86_64 с помощью существующего набора инструментов i686 (32-бит). Загрузите исходный код и распакуйте его, затем следуйте указаниям УСТАНОВИТЬ. Когда вы запустите configure, он обнаружит только 32-разрядную версию и восстановит вас оттуда.
Я также обнаружил, что на CentOS вы можете выполнить
yum update kernel
# reboot
yum update
(из https://geeksterminal.com/how-to-install-glib-glibc/1392/)
SSF
После удаления компоновщика выполнение дополнительных программ невозможно. Все, что у вас есть, - это работающая оболочка bash. Нет wget, нет cp.
Это может происходить двумя способами. Обычное резервное копирование, восстановление и перестройка того, что сделал этот экземпляр, запустите этот процесс сейчас. Или очень творческий подвиг в извлечении из него данных и возвращении в работу glibc.
Необходимо скопировать двоичные файлы, по крайней мере, такие же новые, как EL6 glibc версии 2.12. Только с помощью bash. Теоретически возможно использование только встроенных модулей. На другом хосте распакуйте с помощью rpm2cpio, используйте / dev / tcp /, чтобы загрузить их на сломанный хост. На практике это некрасиво и сложно заставить работать. Необходимо использовать незашифрованные протоколы и вручную ввести запрос.
Вместо этого прикрепите (снимок) образ диска виртуальной машины к другой работающей виртуальной машине EL6 и работайте с ней там. Смонтируйте его где-нибудь, скажем / mnt. Используйте yum, чтобы вернуть glibc, но установите его в сломанный корень:
yum --installroot=/mnt install glibc
Сделайте резервную копию всех важных данных, пока они у вас смонтированы. Снова переместите его на сломанный экземпляр и загрузитесь.
Теперь о вскрытии.
Исправление неисправного экземпляра - это хорошо для восстановления ваших данных, но может оказаться невозможным. Резервные копии остаются восстановлением, которое всегда должно работать. Убедитесь, что восстановление и восстановление возможно.
Вы должны были использовать rpm -e --nodeps попасть в эту ситуацию. Никогда сделай это. Зависимости существуют, потому что пакеты требуют друг друга. описание пакета glibc rpm (rpm -qi glibc) упоминает о его важности, хотя, честно говоря, после множества слов:
Этот конкретный пакет содержит наиболее важные наборы разделяемых библиотек: стандартную библиотеку C и стандартную математическую библиотеку. Без этих двух библиотек система Linux работать не будет.
Если вы не можете выполнить транзакцию rpm с помощью yum, остановитесь. Подвергнуть сомнению целостность базы данных пакетов. Ставьте под сомнение разумность репозиториев yum, которые заставили кого-то задуматься --nodeps когда-либо была хорошей идеей.