Я работал над каталогом с именем bin
. После того, как я закончил, из-за владения bin
и некоторыми файлами в нем я случайно запустил:
sudo rm -r /bin
Вместо:
sudo rm -r bin
Кажется, что мои руки раньше добавьте /
перед всем, что я печатаю.
Как я могу восстановить каталог /bin
?
Мне нужны те же файлы, которые принадлежат моему Ubuntu, я не люблю копировать и вставлять их с живого диска или другого работающего компьютера. система.
Ну, большинство тривиальных и важных утилит установлено в /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
. Вот снимок экрана:
В конце мы принимаем решение переустановить все пакеты или только загрузить и извлечь необходимые файлы к /bin
(который является рекомендуемой опцией):
Можно захватить копию этого сценария или загрузить его непосредственно.
Загрузите свою систему с живым диском, который имеет ту же архитектуру как Ваша установленная 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 для принятия их всех.
И теперь мы сделаны.
Если ваша текущая система все еще имеет запущенную оболочку и доступ в Интернет, это можно сделать с помощью инструментов, существующих в других местах системы. Я предполагаю, что вы только удалили /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
не может извлечь архивы. Мы можем получить две трети пути, потому что:
.deb
файлы на самом деле являются ar
архивами (снова в /usr/bin
):
ar x tar_*.deb
[ 1146] Состоит из двух .tar.*
архивов, data
и control
:
$ echo *.tar.*
control.tar.gz data.tar.xz
В то время как утилиты 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
Примечания:
Мы не можем использовать 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("/")'
/bin/tar
вам все равно нужно извлечь некоторые файлы deb. прежде чем вы сможете использовать apt-get
: оболочки, coreutils и т. д. Проще просто извлечь их все и переустановить позже. Некоторые дополнения к этому превосходному ответу, после того, как я встретился с этой проблемой (наряду с удалением /boot
, /etc
, /lib
и /lib64
):
chroot
требует /lib
и /lib64
присутствовать; иначе Вы получите следующую ошибку:failed to run command ‘/bin/bash’: No such file or directory
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/*
Вы могли временно помещенные файлы с живого CD или другой системы в Ваш /bin
, чтобы сделать Вашу систему применимой, затем заменить их файлами от Вашей установки Ubuntu путем выполнения apt-get install --reinstall
для пакетов, которые имеют материал в /bin
.
if
делает некоторые противные вещи, и это на самом деле повредит конфигурации HTTPS также как it' ll заканчиваются в бесконечном цикле перенаправления даже для Запросов HTTPS. Необходимо всегда использовать два отдельных блока сервера; один для не-SSL и один для SSL. Или, один блок сервера для одного набора имен серверов, и затем тестирует схему, но если все еще нечетно.
– Thomas Ward♦
8 April 2019 в 16:32