Случайно удален / bin. Как мне его восстановить?

Я работал над каталогом с именем bin. После того, как я закончил, из-за владения bin и некоторыми файлами в нем я случайно запустил:

sudo rm -r /bin

Вместо:

sudo rm -r bin

Кажется, что мои руки раньше добавьте / перед всем, что я печатаю.

Как я могу восстановить каталог /bin?

Мне нужны те же файлы, которые принадлежат моему Ubuntu, я не люблю копировать и вставлять их с живого диска или другого работающего компьютера. система.

93
задан 21 April 2017 в 23:11

4 ответа

Действительно ли это возможно?

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

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


Как?

Во-первых, мы должны chroot в Вашу поврежденную систему, но с незначительными различиями! После этого мы получим список установленных пакетов в Вашей системе, которые имеют любой установленный файл в /bin каталог, затем мы собираемся только загрузить необходимые пакеты и извлечь необходимые файлы в /bin. Затем мы будем сделаны.

Например, после chroot, мы можем получить список пакетов, которые установили файлы в /bin использование:

dpkg --search /bin | cut -f1 -d: | tr ',' '\n'

И мы можем также использовать:

dpkg --listfiles PACKAGE-NAME | grep "^/bin/" # or awk '$0 ~ "^/bin/

перечислять установленные файлы этими пакетами в /bin.

Затем мы просто создаем список всех пакетов, которые необходимы для нас, затем загружают их и извлекают их к /bin с чем-то как:

xargs apt download < list-packages
dpkg-deb -x PACKAGE .
mv ./bin/* /bin

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

Таким образом, я записал сценарий, который делает все, в чем мы нуждаемся. Это находит, что все необходимые пакеты для нас восстанавливают /bin, показывает нам название каждого пакета и их связанных файлов, который принадлежит /bin. Вот снимок экрана:

Screenshot of <code>/bin</code> package list as output by my script

В конце мы принимаем решение переустановить все пакеты или только загрузить и извлечь необходимые файлы к /bin (который является рекомендуемой опцией):

Screenshot of options given by my script

Можно захватить копию этого сценария или загрузить его непосредственно.


Позволяет запускаются

chroot

Загрузите свою систему с живым диском, который имеет ту же архитектуру как Ваша установленная Ubuntu, откройте терминал и получите корневой доступ:

sudo -i

Смонтируйте Ваш root файловая система (для меня это /dev/sda1):

mount /dev/sda1 /mnt

Нам будет нужна возможность соединения к Интернету, так копия resolv.conf от живой Ubuntu до Вашего смонтированного корневого раздела:

cp /etc/resolv.conf /mnt/etc/resolv.conf

Теперь скопируйте сценарий в где-нибудь на смонтированном разделе, например:

cp /media/ubuntu/usb/restore-bin.sh /mnt/restore-bin.sh

или можно загрузить его использование wget, и т.д. как:

wget https://git.io/v9fRm -O /mnt/restore-bin.sh

Смонтируйте другие необходимые пути:

mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
mount -t proc /proc /mnt/proc

И вот незначительные различия: как может мы chroot к поврежденной системе, когда существует нет /bin каталог там? Какую оболочку мы должны выполнить?

Поэтому создайте временный каталог bin. например: именованный bintmp в Вашем поврежденном системном корне:

mkdir /mnt/bintmp

Затем свяжите живое /bin в это:

mount --bind /bin /mnt/bintmp

Chroot в систему при установке /bintmp/bash как Ваша оболочка входа в систему:

chroot /mnt /bintmp/bash

Экспортируйте /bintmp как Ваш PATH переменная среды:

export PATH=/bintmp:$PATH

Дайте сценарию исполняемый бит:

chmod +x restore-bin.sh

Запустите скрипт:

./restore-bin.sh

Ожидайте поиска, который будет завершен, затем отвечают на вопрос, который мы видели в снимке экрана. Это начнет восстанавливать /bin и мы почти сделаны.

После того, как это будет сделано, используйте CTRL+D для выхода chroot среда и размонтирование смонтированные пути:

umount -R /mnt

Перезагрузите систему.

Восстановление ссылок в /bin

Теперь почти все файлы в /bin каталог вернулся, приблизительно кроме 5 символьных ссылок, которыми управляют update-alternatives.

В Вашей рабочей системе, выполненной:

sudo update-alternatives --all

Это задает Вам некоторые вопросы; можно просто нажать ENTER для принятия их всех.

И теперь мы сделаны.

182
ответ дан 21 April 2017 в 23:11

Если ваша текущая система все еще имеет запущенную оболочку и доступ в Интернет, это можно сделать с помощью инструментов, существующих в других местах системы. Я предполагаю, что вы только удалили /bin. /bin, конечно, имеет самую удобную утилиту, которую вы могли бы использовать в такой ситуации (busybox), но без этого нам придется проявить немного творчества.


Поскольку у вас уже есть работающая оболочка, а поскольку sudo находится в /usr/bin, давайте возьмем себе работающую корневую оболочку, прежде чем наносить дальнейший ущерб. Но /bin/bash и большинство других оболочек исчезли! К счастью, в Linux все еще есть копия оболочки, которую вы используете. Итак:

sudo /proc/$/exe

Строго говоря, нам не нужна корневая оболочка для большей части следующего. Но все равно.

Теперь, dpkg все еще работает, по крайней мере, для определения, какие пакеты имеют файлы в /bin:

dpkg -S /bin

Мы можем использовать awk, чтобы обработать его и получить имена пакетов, и [ 1119] и apt-get для загрузки пакетов (все в /usr/bin). Если у вас есть временный каталог, который вы можете использовать, cd там, потому что ваш текущий каталог будет немного запутанным:

dpkg -S /bin | awk -F '[, :]' '{NF--}1' | xargs apt-get download

Теперь самая большая проблема у нас заключается в том, что /bin/tar отсутствует, и без него dpkg не может извлечь архивы. Мы можем получить две трети пути, потому что:

  1. .deb файлы на самом деле являются ar архивами (снова в /usr/bin):

    ar x tar_*.deb
    
    [ 1146]
  2. Состоит из двух .tar.* архивов, data и control:

    $ echo *.tar.*
    control.tar.gz data.tar.xz
    
  3. В то время как утилиты gzip находятся в /bin, [ 1132] находится в /usr/bin:

    unxz data.tar.xz
    

Теперь у нас есть файл data.tar без tar для извлечения tar из него.

Питон на помощь ! Вот где действительно требуется sudo:

$ sudo python -c 'import tarfile; tarfile.open("data.tar").extractall("/")'
$ echo /bin/*
/bin/tar

Теперь мы можем использовать dpkg для извлечения оставшихся файлов deb, чтобы получить достаточно полный /bin:

for i in *.deb; do dpkg-deb -x "$i" /; done

Однако, мы все равно должны сделать правильную установку файлов deb, чтобы символические ссылки и т. Д., Которые были бы созданы пакетами, были воссозданы:

sudo apt install --reinstall ./*.deb

Или:

sudo dpkg -i *.deb
sudo apt-get install -f

Примечания:

  1. Мы не можем использовать Python 2 для непосредственного извлечения файла data.tar.xz, поскольку Python 2 поддерживает только сжатие gzip и bzip2. Python 3, однако, поддерживает его, поэтому вы можете использовать Python 3 напрямую без unxz:

    sudo python3 -c 'import tarfile; tarfile.open("data.tar.xz").extractall("/")'
    
  2. После возвращения /bin/tar вам все равно нужно извлечь некоторые файлы deb. прежде чем вы сможете использовать apt-get: оболочки, coreutils и т. д. Проще просто извлечь их все и переустановить позже.
0
ответ дан 21 April 2017 в 23:11

Некоторые дополнения к этому превосходному ответу, после того, как я встретился с этой проблемой (наряду с удалением /boot, /etc, /lib и /lib64):

  • chroot требует /lib и /lib64 присутствовать; иначе Вы получите следующую ошибку:
    failed to run command ‘/bin/bash’: No such file or directory
    Я скопировал их с ОС LiveCD и не имел никаких проблем при восстановлении. YMMV в зависимости от пакетов Вы установили в системе
  • Я не могу отредактировать ответ, на который ссылаются выше, но существует опечатка:
    cp /etc/resolv.conf /mnt/etc/resolv.cof
    должен быть
    cp /etc/resolv.conf /mnt/etc/resolv.conf
  • /boot может легко быть восстановлен с помощью инструментов личинки. Посмотрите здесь.
  • Поскольку этот ответ рекомендует, apt install --reinstall <package> отличный способ состоит в том, чтобы восстановить недостающие файлы в /bin, /lib и /lib64.
    • Некоторые пакеты, которые потребовали переустановки: libaio1, mysql-server, openvpn, vsftpd

Отметьте к сам:
rm -rf folder /* не то же как rm -rf folder/*

1
ответ дан 21 April 2017 в 23:11

Вы могли временно помещенные файлы с живого CD или другой системы в Ваш /bin, чтобы сделать Вашу систему применимой, затем заменить их файлами от Вашей установки Ubuntu путем выполнения apt-get install --reinstall для пакетов, которые имеют материал в /bin.

7
ответ дан 22 April 2017 в 09:11
  • 1
    if делает некоторые противные вещи, и это на самом деле повредит конфигурации HTTPS также как it' ll заканчиваются в бесконечном цикле перенаправления даже для Запросов HTTPS. Необходимо всегда использовать два отдельных блока сервера; один для не-SSL и один для SSL. Или, один блок сервера для одного набора имен серверов, и затем тестирует схему, но если все еще нечетно. – Thomas Ward♦ 8 April 2019 в 16:32

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

Похожие вопросы: