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

Question 1

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

sudo rm -r /bin

Вместо:

sudo rm -r bin

Кажется, что мои руки

Как восстановить исходный каталог /bin?

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

Question 2

Возможно ли это?

Ну, самые тривиальные и важные утилиты установлены в /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 (что является рекомендуемым вариантом):

Вы можете получить копию этого скрипта или загрузить его напрямую.

Запустится

chroot

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

sudo -i

Установите ваш [ f30] (для меня это /dev/sda1):

mount /dev/sda1 /mnt

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

[ f6]

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

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. например: named bintmp внутри вашего сломанного системного корня:

mkdir /mnt/bintmp

Затем привяжите живой /bin к этому:

mount --bind /bin /mnt/bintmp

Вставьте ручку в систему, установив [ f38] в качестве вашей оболочки входа:

chroot /mnt /bintmp/bash

Экспортировать /bintmp в качестве переменной среды PATH:

export PATH=/bintmp:$PATH

Дать скрипту исполняемый бит: [!d38 ]

chmod +x restore-bin.sh

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

./restore-bin.sh

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

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

umount -R /mnt

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

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

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

В вашей запущенной системе запустите:

sudo update-alternatives --all

Он задает вам несколько вопросов; вы можете просто нажать CTRL , чтобы принять их все.

И теперь мы закончили.

Question 3

Question 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. Вот скриншот:

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

Вы можете получить копию этого скрипта или загрузить его напрямую.

Запустится

chroot

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

sudo -i

Установите ваш root (для меня это /dev/sda1):

mount /dev/sda1 /mnt

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

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

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

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. например: named bintmp внутри вашего сломанного системного корня:

mkdir /mnt/bintmp

Затем привяжите живой /bin к этому:

mount --bind /bin /mnt/bintmp

Вставьте ручку в систему, установив /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

Он задает вам несколько вопросов; вы можете просто нажать CTRL , чтобы принять их все.

И теперь мы закончили.

Question 5

Возможно ли это?

Ну, самые тривиальные и важные утилиты установлены в /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 (что является рекомендуемым вариантом):

Вы можете получить копию этого скрипта или загрузить его напрямую.

Запустится

chroot

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

sudo -i

Установите ваш root (для меня это /dev/sda1):

mount /dev/sda1 /mnt

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

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

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

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. например: named bintmp внутри вашего сломанного системного корня:

mkdir /mnt/bintmp

Затем привяжите живой /bin к этому:

mount --bind /bin /mnt/bintmp

Вставьте ручку в систему, установив /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

Он задает вам несколько вопросов; вы можете просто нажать CTRL , чтобы принять их все.

И теперь мы закончили.

Question 6

Возможно ли это?

Ну, самые тривиальные и важные утилиты установлены в /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 (что является рекомендуемым вариантом):

Вы можете получить копию этого скрипта или загрузить его напрямую.

Запустится

chroot

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

sudo -i

Установите ваш root (для меня это /dev/sda1):

mount /dev/sda1 /mnt

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

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

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

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. например: named bintmp внутри вашего сломанного системного корня:

mkdir /mnt/bintmp

Затем привяжите живой /bin к этому:

mount --bind /bin /mnt/bintmp

Вставьте ручку в систему, установив /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

Он задает вам несколько вопросов; вы можете просто нажать CTRL , чтобы принять их все.

И теперь мы закончили.

Question 7

Question 8

Возможно ли это?

Ну, самые тривиальные и важные утилиты установлены в /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 (что является рекомендуемым вариантом):

Вы можете получить копию этого скрипта или загрузить его напрямую.

Запустится

chroot

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

sudo -i

Установите ваш root (для меня это /dev/sda1):

mount /dev/sda1 /mnt

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

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

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

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. например: named bintmp внутри вашего сломанного системного корня:

mkdir /mnt/bintmp

Затем привяжите живой /bin к этому:

mount --bind /bin /mnt/bintmp

Вставьте ручку в систему, установив /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

Он задает вам несколько вопросов; вы можете просто нажать CTRL , чтобы принять их все.

И теперь мы закончили.

Question 9

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

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

sudo /proc/$$/exe

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

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

dpkg -S /bin

Мы можем использовать awk для его обработки и получить имена пакетов и xargs и 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

Состоит из двух архивов .tar.*, [ f30] и control:

$ echo *.tar.*
control.tar.gz data.tar.xz

Хотя утилиты gzip находятся в /bin, unxz находится в /usr/bin:

unxz data.tar.xz

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

Python на помощь! Здесь 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

Примечания:

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

ar x tar_*.deb

После получения назад /bin/tar, вам все равно нужно извлечь некоторые из файлов deb, прежде чем вы сможете использовать apt-get: оболочки, coreutils и т. д. Легче просто извлечь все из них и переустановить позже.

Question 10

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

Question 11

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

Question 12

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

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

Примечание для себя: rm -rf folder /* не совпадает с rm -rf folder/*

Question 13

Question 14

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

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

sudo /proc/$$/exe

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

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

dpkg -S /bin

Мы можем использовать awk для его обработки и получить имена пакетов и xargs и 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

Состоит из двух архивов .tar.*, data и control:

$ echo *.tar.*
control.tar.gz data.tar.xz

Хотя утилиты gzip находятся в /bin, unxz находится в /usr/bin:

unxz data.tar.xz

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

Python на помощь! Здесь 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

Примечания:

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

ar x tar_*.deb

После получения назад /bin/tar, вам все равно нужно извлечь некоторые из файлов deb, прежде чем вы сможете использовать apt-get: оболочки, coreutils и т. д. Легче просто извлечь все из них и переустановить позже.

Question 15

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

Question 16

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

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

Примечание для себя: rm -rf folder /* не совпадает с rm -rf folder/*

Question 17

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

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

sudo /proc/$$/exe

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

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

dpkg -S /bin

Мы можем использовать awk для его обработки и получить имена пакетов и xargs и 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

Состоит из двух архивов .tar.*, data и control:

$ echo *.tar.*
control.tar.gz data.tar.xz

Хотя утилиты gzip находятся в /bin, unxz находится в /usr/bin:

unxz data.tar.xz

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

Python на помощь! Здесь 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

Примечания:

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

ar x tar_*.deb

После получения назад /bin/tar, вам все равно нужно извлечь некоторые из файлов deb, прежде чем вы сможете использовать apt-get: оболочки, coreutils и т. д. Легче просто извлечь все из них и переустановить позже.

Question 18

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

Question 19

Question 20

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

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

Примечание для себя: rm -rf folder /* не совпадает с rm -rf folder/*

Question 21

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

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

sudo /proc/$$/exe

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

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

dpkg -S /bin

Мы можем использовать awk для его обработки и получить имена пакетов и xargs и 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

Состоит из двух архивов .tar.*, data и control:

$ echo *.tar.*
control.tar.gz data.tar.xz

Хотя утилиты gzip находятся в /bin, unxz находится в /usr/bin:

unxz data.tar.xz

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

Python на помощь! Здесь 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

Примечания:

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

ar x tar_*.deb

После получения назад /bin/tar, вам все равно нужно извлечь некоторые из файлов deb, прежде чем вы сможете использовать apt-get: оболочки, coreutils и т. д. Легче просто извлечь все из них и переустановить позже.

Question 22

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

Question 23

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

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

Примечание для себя: rm -rf folder /* не совпадает с rm -rf folder/*

Question 24

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

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

sudo /proc/$$/exe

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

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

dpkg -S /bin

Мы можем использовать awk для его обработки и получить имена пакетов и xargs и 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

Состоит из двух архивов .tar.*, data и control:

$ echo *.tar.*
control.tar.gz data.tar.xz

Хотя утилиты gzip находятся в /bin, unxz находится в /usr/bin:

unxz data.tar.xz

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

Python на помощь! Здесь 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

Примечания:

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

ar x tar_*.deb

После получения назад /bin/tar, вам все равно нужно извлечь некоторые из файлов deb, прежде чем вы сможете использовать apt-get: оболочки, coreutils и т. д. Легче просто извлечь все из них и переустановить позже.

terdon · Accepted Answer · 22 May 2018 в 23:26

Возможно ли это?

Ну, самые тривиальные и важные утилиты установлены в /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 (что является рекомендуемым вариантом):

Вы можете получить копию этого скрипта или загрузить его напрямую.

Запустится

chroot

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

sudo -i

Установите ваш [ f30] (для меня это /dev/sda1):

mount /dev/sda1 /mnt

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

[ f6]

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

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. например: named bintmp внутри вашего сломанного системного корня:

mkdir /mnt/bintmp

Затем привяжите живой /bin к этому:

mount --bind /bin /mnt/bintmp

Вставьте ручку в систему, установив [ f38] в качестве вашей оболочки входа:

chroot /mnt /bintmp/bash

Экспортировать /bintmp в качестве переменной среды PATH:

export PATH=/bintmp:$PATH

Дать скрипту исполняемый бит: [!d38 ]

chmod +x restore-bin.sh

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

./restore-bin.sh

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

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

umount -R /mnt

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

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

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

В вашей запущенной системе запустите:

sudo update-alternatives --all

Он задает вам несколько вопросов; вы можете просто нажать CTRL , чтобы принять их все.

И теперь мы закончили.

Это, без сомнения, лучший ответ, который я видел на Ask Ubuntu. Очень мило с вашей стороны идти на столько работы, зная, что ОП находится в неудобной ситуации. — Nonny Moose, 20 April 2017 в 03:46
О, подожди, т. Д. Я должен был понять, что ты это сделал. — Nonny Moose, 20 April 2017 в 04:27
Это потрясающе. Мне нравится, как дизайн SE не дает никакого намека на то, что это вопрос с автоответчиком. — Hamsterrific, 23 April 2017 в 19:43
@Hamsteriffic это: см. Прямоугольник, содержащий имя ответчика (подпись): он имеет более темный фон, который нет в сообщениях не OP. Это касается комментариев, ответов и вопросов. — Ruslan, 23 April 2017 в 21:44

terdon · Accepted Answer · 18 July 2018 в 14:38

Возможно ли это?

Ну, самые тривиальные и важные утилиты установлены в /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 (что является рекомендуемым вариантом):

Вы можете получить копию этого скрипта или загрузить его напрямую.

Запустится

chroot

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

sudo -i

Установите ваш root (для меня это /dev/sda1):

mount /dev/sda1 /mnt

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

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

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

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. например: named bintmp внутри вашего сломанного системного корня:

mkdir /mnt/bintmp

Затем привяжите живой /bin к этому:

mount --bind /bin /mnt/bintmp

Вставьте ручку в систему, установив /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

Он задает вам несколько вопросов; вы можете просто нажать CTRL , чтобы принять их все.

И теперь мы закончили.

terdon · Accepted Answer · 24 July 2018 в 20:26

Возможно ли это?

Ну, самые тривиальные и важные утилиты установлены в /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 (что является рекомендуемым вариантом):

Вы можете получить копию этого скрипта или загрузить его напрямую.

Запустится

chroot

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

sudo -i

Установите ваш root (для меня это /dev/sda1):

mount /dev/sda1 /mnt

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

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

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

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. например: named bintmp внутри вашего сломанного системного корня:

mkdir /mnt/bintmp

Затем привяжите живой /bin к этому:

mount --bind /bin /mnt/bintmp

Вставьте ручку в систему, установив /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

Он задает вам несколько вопросов; вы можете просто нажать CTRL , чтобы принять их все.

И теперь мы закончили.

terdon · Accepted Answer · 31 July 2018 в 10:26

Возможно ли это?

Ну, самые тривиальные и важные утилиты установлены в /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 (что является рекомендуемым вариантом):

Вы можете получить копию этого скрипта или загрузить его напрямую.

Запустится

chroot

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

sudo -i

Установите ваш root (для меня это /dev/sda1):

mount /dev/sda1 /mnt

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

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

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

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. например: named bintmp внутри вашего сломанного системного корня:

mkdir /mnt/bintmp

Затем привяжите живой /bin к этому:

mount --bind /bin /mnt/bintmp

Вставьте ручку в систему, установив /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

Он задает вам несколько вопросов; вы можете просто нажать CTRL , чтобы принять их все.

И теперь мы закончили.

terdon · Accepted Answer · 31 July 2018 в 11:28

Возможно ли это?

Ну, самые тривиальные и важные утилиты установлены в /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 (что является рекомендуемым вариантом):

Вы можете получить копию этого скрипта или загрузить его напрямую.

Запустится

chroot

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

sudo -i

Установите ваш root (для меня это /dev/sda1):

mount /dev/sda1 /mnt

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

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

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

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. например: named bintmp внутри вашего сломанного системного корня:

mkdir /mnt/bintmp

Затем привяжите живой /bin к этому:

mount --bind /bin /mnt/bintmp

Вставьте ручку в систему, установив /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

Он задает вам несколько вопросов; вы можете просто нажать CTRL , чтобы принять их все.

И теперь мы закончили.

muru · Answer 6 · 22 May 2018 в 23:26

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

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

sudo /proc/$$/exe

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

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

dpkg -S /bin

Мы можем использовать awk для его обработки и получить имена пакетов и xargs и 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

Состоит из двух архивов .tar.*, [ f30] и control:

$ echo *.tar.*
control.tar.gz data.tar.xz

Хотя утилиты gzip находятся в /bin, unxz находится в /usr/bin:

unxz data.tar.xz

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

Python на помощь! Здесь 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

Примечания:

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

ar x tar_*.deb

После получения назад /bin/tar, вам все равно нужно извлечь некоторые из файлов deb, прежде чем вы сможете использовать apt-get: оболочки, coreutils и т. д. Легче просто извлечь все из них и переустановить позже.

Я не тестировал его, но я почти полностью его прочитал, это было потрясающе, на самом деле я попытался найти копию памяти в памяти, немного искал, я не нашел ничего интересного и после того, как увидел, что смола не в /usr/bin, я сказал, что бы ни пошел с хрутом ... Удивительно. — Ravexina, 19 April 2017 в 19:00
Вопрос, не является ли /proc/$$/exe ссылкой на /bin/bash? как это работает, когда /bin удаляется? (Это работает, но как), я думал, что это должна быть неработающая ссылка ... вот почему я оставил эту идею позади. — Ravexina, 19 April 2017 в 19:13
@Ravexina не получил полного ответа, но: Как символическая ссылка / proc / & lt; pid & gt; / exe отличается от обычных символических ссылок? — muru, 19 April 2017 в 19:14
PATH = / usr / lib / klibc / bin: $ PATH поместит cat и sh обратно на ваш путь — Joshua, 21 April 2017 в 06:05
@Joshua И каждый из них статически связан! Ницца! — muru, 21 April 2017 в 06:51

Dmitry Grigoryev · Answer 7 · 22 May 2018 в 23:26

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

7

ответ дан Dmitry Grigoryev 22 May 2018 в 23:26

1

Это то, что я сделал бы. Живой DVD, являющийся одним и тем же номером версии, будет почти таким же, если не совсем то же самое, что и текущий. Если бы у меня был диск или версия USB Live, я мог бы сравнить их и опубликовать ответ, подобный вашему. Этот поток является скорее теорией, если OP никогда не удалялся / bin, в первую очередь, что является возможностью, поскольку он написал ответ в то же время, что и вопрос, по всей вероятности. Еще очень приятный мысленный эксперимент и отличный стиль письма. – WinEunuuchs2Unix 22 April 2017 в 01:12
2

Я рекомендую изменить этот ответ, чтобы развернуть его с подробными сведениями о том, как это сделать. (См. Также Как написать хороший ответ? для общих советов о том, какие ответы наиболее ценны для AskUbuntu.) – David Foerster 7 May 2017 в 17:36

Dmitry Grigoryev · Answer 8 · 18 July 2018 в 14:38

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

mrtumnus · Answer 9 · 18 July 2018 в 14:38

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

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

Примечание для себя: rm -rf folder /* не совпадает с rm -rf folder/*

muru · Answer 10 · 18 July 2018 в 14:38

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

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

sudo /proc/$$/exe

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

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

dpkg -S /bin

Мы можем использовать awk для его обработки и получить имена пакетов и xargs и 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

Состоит из двух архивов .tar.*, data и control:

$ echo *.tar.*
control.tar.gz data.tar.xz

Хотя утилиты gzip находятся в /bin, unxz находится в /usr/bin:

unxz data.tar.xz

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

Python на помощь! Здесь 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

Примечания:

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

ar x tar_*.deb

После получения назад /bin/tar, вам все равно нужно извлечь некоторые из файлов deb, прежде чем вы сможете использовать apt-get: оболочки, coreutils и т. д. Легче просто извлечь все из них и переустановить позже.

Dmitry Grigoryev · Answer 11 · 24 July 2018 в 20:26

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

7

ответ дан Dmitry Grigoryev 24 July 2018 в 20:26

1

Это то, что я сделал бы. Живой DVD, являющийся одним и тем же номером версии, будет почти таким же, если не совсем то же самое, что и текущий. Если бы у меня был диск или версия USB Live, я мог бы сравнить их и опубликовать ответ, подобный вашему. Этот поток является скорее теорией, если OP никогда не удалялся / bin, в первую очередь, что является возможностью, поскольку он написал ответ в то же время, что и вопрос, по всей вероятности. Еще очень приятный мысленный эксперимент и отличный стиль письма. – WinEunuuchs2Unix 22 April 2017 в 01:12
2

Я рекомендую изменить этот ответ, чтобы развернуть его с подробными сведениями о том, как это сделать. (См. Также Как написать хороший ответ? для общих советов о том, какие ответы наиболее ценны для AskUbuntu.) – David Foerster 7 May 2017 в 17:36

mrtumnus · Answer 12 · 24 July 2018 в 20:26

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

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

Примечание для себя: rm -rf folder /* не совпадает с rm -rf folder/*

muru · Answer 13 · 24 July 2018 в 20:26

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

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

sudo /proc/$$/exe

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

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

dpkg -S /bin

Мы можем использовать awk для его обработки и получить имена пакетов и xargs и 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

Состоит из двух архивов .tar.*, data и control:

$ echo *.tar.*
control.tar.gz data.tar.xz

Хотя утилиты gzip находятся в /bin, unxz находится в /usr/bin:

unxz data.tar.xz

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

Python на помощь! Здесь 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

Примечания:

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

ar x tar_*.deb

После получения назад /bin/tar, вам все равно нужно извлечь некоторые из файлов deb, прежде чем вы сможете использовать apt-get: оболочки, coreutils и т. д. Легче просто извлечь все из них и переустановить позже.

Я не тестировал его, но я почти полностью его прочитал, это было потрясающе, на самом деле я попытался найти копию памяти в памяти, немного искал, я не нашел ничего интересного и после того, как увидел, что смола не в /usr/bin, я сказал, что бы ни пошел с хрутом ... Удивительно. — Ravexina, 19 April 2017 в 19:00
Вопрос, не является ли /proc/$$/exe ссылкой на /bin/bash? как это работает, когда /bin удаляется? (Это работает, но как), я думал, что это должна быть неработающая ссылка ... вот почему я оставил эту идею позади. — Ravexina, 19 April 2017 в 19:13
@Ravexina не получил полного ответа, но: Как символическая ссылка / proc / & lt; pid & gt; / exe отличается от обычных символических ссылок? — muru, 19 April 2017 в 19:14
PATH = / usr / lib / klibc / bin: $ PATH поместит cat и sh обратно на ваш путь — Joshua, 21 April 2017 в 06:05
@Joshua И каждый из них статически связан! Ницца! — muru, 21 April 2017 в 06:51

Dmitry Grigoryev · Answer 14 · 31 July 2018 в 10:26

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

7

ответ дан Dmitry Grigoryev 31 July 2018 в 10:26

1

Это то, что я сделал бы. Живой DVD, являющийся одним и тем же номером версии, будет почти таким же, если не совсем то же самое, что и текущий. Если бы у меня был диск или версия USB Live, я мог бы сравнить их и опубликовать ответ, подобный вашему. Этот поток является скорее теорией, если OP никогда не удалялся / bin, в первую очередь, что является возможностью, поскольку он написал ответ в то же время, что и вопрос, по всей вероятности. Еще очень приятный мысленный эксперимент и отличный стиль письма. – WinEunuuchs2Unix 22 April 2017 в 01:12
2

Я рекомендую изменить этот ответ, чтобы развернуть его с подробными сведениями о том, как это сделать. (См. Также Как написать хороший ответ? для общих советов о том, какие ответы наиболее ценны для AskUbuntu.) – David Foerster 7 May 2017 в 17:36

mrtumnus · Answer 15 · 31 July 2018 в 10:26

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

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

Примечание для себя: rm -rf folder /* не совпадает с rm -rf folder/*

muru · Answer 16 · 31 July 2018 в 10:26

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

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

sudo /proc/$$/exe

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

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

dpkg -S /bin

Мы можем использовать awk для его обработки и получить имена пакетов и xargs и 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

Состоит из двух архивов .tar.*, data и control:

$ echo *.tar.*
control.tar.gz data.tar.xz

Хотя утилиты gzip находятся в /bin, unxz находится в /usr/bin:

unxz data.tar.xz

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

Python на помощь! Здесь 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

Примечания:

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

ar x tar_*.deb

После получения назад /bin/tar, вам все равно нужно извлечь некоторые из файлов deb, прежде чем вы сможете использовать apt-get: оболочки, coreutils и т. д. Легче просто извлечь все из них и переустановить позже.

Я не тестировал его, но я почти полностью его прочитал, это было потрясающе, на самом деле я попытался найти копию памяти в памяти, немного искал, я не нашел ничего интересного и после того, как увидел, что смола не в /usr/bin, я сказал, что бы ни пошел с хрутом ... Удивительно. — Ravexina, 19 April 2017 в 19:00
Вопрос, не является ли /proc/$$/exe ссылкой на /bin/bash? как это работает, когда /bin удаляется? (Это работает, но как), я думал, что это должна быть неработающая ссылка ... вот почему я оставил эту идею позади. — Ravexina, 19 April 2017 в 19:13
@Ravexina не получил полного ответа, но: Как символическая ссылка / proc / & lt; pid & gt; / exe отличается от обычных символических ссылок? — muru, 19 April 2017 в 19:14
PATH = / usr / lib / klibc / bin: $ PATH поместит cat и sh обратно на ваш путь — Joshua, 21 April 2017 в 06:05
@Joshua И каждый из них статически связан! Ницца! — muru, 21 April 2017 в 06:51

Dmitry Grigoryev · Answer 17 · 31 July 2018 в 11:28

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

7

ответ дан Dmitry Grigoryev 31 July 2018 в 11:28

1

Это то, что я сделал бы. Живой DVD, являющийся одним и тем же номером версии, будет почти таким же, если не совсем то же самое, что и текущий. Если бы у меня был диск или версия USB Live, я мог бы сравнить их и опубликовать ответ, подобный вашему. Этот поток является скорее теорией, если OP никогда не удалялся / bin, в первую очередь, что является возможностью, поскольку он написал ответ в то же время, что и вопрос, по всей вероятности. Еще очень приятный мысленный эксперимент и отличный стиль письма. – WinEunuuchs2Unix 22 April 2017 в 01:12
2

Я рекомендую изменить этот ответ, чтобы развернуть его с подробными сведениями о том, как это сделать. (См. Также Как написать хороший ответ? для общих советов о том, какие ответы наиболее ценны для AskUbuntu.) – David Foerster 7 May 2017 в 17:36

mrtumnus · Answer 18 · 31 July 2018 в 11:28

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

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

Примечание для себя: rm -rf folder /* не совпадает с rm -rf folder/*

muru · Answer 19 · 31 July 2018 в 11:28

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

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

sudo /proc/$$/exe

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

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

dpkg -S /bin

Мы можем использовать awk для его обработки и получить имена пакетов и xargs и 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

Состоит из двух архивов .tar.*, data и control:

$ echo *.tar.*
control.tar.gz data.tar.xz

Хотя утилиты gzip находятся в /bin, unxz находится в /usr/bin:

unxz data.tar.xz

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

Python на помощь! Здесь 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

Примечания:

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

ar x tar_*.deb

После получения назад /bin/tar, вам все равно нужно извлечь некоторые из файлов deb, прежде чем вы сможете использовать apt-get: оболочки, coreutils и т. д. Легче просто извлечь все из них и переустановить позже.

Я не тестировал его, но я почти полностью его прочитал, это было потрясающе, на самом деле я попытался найти копию памяти в памяти, немного искал, я не нашел ничего интересного и после того, как увидел, что смола не в /usr/bin, я сказал, что бы ни пошел с хрутом ... Удивительно. — Ravexina, 19 April 2017 в 19:00
Вопрос, не является ли /proc/$$/exe ссылкой на /bin/bash? как это работает, когда /bin удаляется? (Это работает, но как), я думал, что это должна быть неработающая ссылка ... вот почему я оставил эту идею позади. — Ravexina, 19 April 2017 в 19:13
@Ravexina не получил полного ответа, но: Как символическая ссылка / proc / & lt; pid & gt; / exe отличается от обычных символических ссылок? — muru, 19 April 2017 в 19:14
PATH = / usr / lib / klibc / bin: $ PATH поместит cat и sh обратно на ваш путь — Joshua, 21 April 2017 в 06:05
@Joshua И каждый из них статически связан! Ницца! — muru, 21 April 2017 в 06:51

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

19 ответов

Возможно ли это?

Как?

Запустится

chroot

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

Возможно ли это?

Как?

Запустится

chroot

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

Возможно ли это?

Как?

Запустится

chroot

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

Возможно ли это?

Как?

Запустится

chroot

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

Возможно ли это?

Как?

Запустится

chroot

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

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

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