Содержимое /bin перемещено в /usr/bin, можно отменить?
guau,
la versión reciente de los controladores 1.3.28.x64 no funcionó, el paquete iscan -gt -s650 -obviamente más antiguo -1.0.0.x64 sí lo hizo.
misión adicional:
¿Existe la posibilidad de asignar uno de los botones de hardware ()en el escáner para escanear directamente? (Solo lo uso para documentos, por lo que la configuración sigue siendo la misma de todos modos)
Is my Ubuntu in a broken state now?
Да, ваш Ubuntu не работает
Вы испортили что-то важное в управлении пакетами .
Так что на практике сделайте резервную копию важных данных (по крайней мере /etcи /home), возможно также список установленных пакетов, например. вывод dpkg -lи переустановите Ubuntu.
(не -новичок мог бы попытаться справиться с -как и в других ответах -, но тогда он не сделал бы такой огромной и принципиальной ошибки)
I could just admit to screwup reinstall the whole linux partition.
Вероятно, это отнимет у вас меньше времени. Поддерживать вашу текущую систему с помощью других ответов — значит держать ее в очень грязном состоянии (, что принесет вам головную боль в будущем ).
Поскольку вы переформатируете диск, подумайте о том, чтобы поместить /homeв отдельный раздел (, чтобы в будущем такие ошибки не привели к потере ваших данных ). Прежде чем сделать это, напечатайте на бумаге вывод df -h, df -hiи fdisk -l(, они дают информацию о дисковом пространстве -как используемом, так и доступном -... ). Будьте мудры, чтобы иметь достаточно большой системный раздел (корневой файловой системы ); если вы можете себе это позволить, 100 Гбайт более чем достаточно.
I was supposed to move the software bin -folder contents to /usr/bin
(терминология :В Unix есть каталоги, а не "папки" ).
То, что(перемещает в /usr/bin/), очень неправильно. Либо улучшите ваш $PATH (, предпочтительно ), либо в лучшем случае добавьте символические ссылки в /usr/bin/и предпочтительно переместите (или добавьте символические ссылки )исполняемых файлов в /usr/local/bin/.
Мудрый подход заключается в том, чтобы никогда не изменять /usr/bin/, /bin, /sbin, /usr/sbin/вне инструментов управления пакетами (, например. dpkg, apt-get, aptitudeи т.д... ). Прочтите FHS .
В Linux (и в большинстве других систем, хотя POSIX не дает такой гарантии, если только перемещение не было выполнено между файловыми системами ), это могло бы обновить их ctime, поэтому предполагается, что ни одно из других в /usr/binбыли затронуты за последние 24 часа, вы сможете вернуть их обратно с помощью:
find /usr/bin/. ! -name. -prune -ctime -1 -exec sh -c '
echo mv -i "$@" /bin' sh {} +
Удалите echo, если это выглядит правильно. Обратите внимание, что вы не сможете восстановить файлы, существовавшие под тем же именем в /binи /usr/bin(, исходные файлы в /usr/binбыли бы потеряны)
Потенциальное предостережение: :если некоторые файлы были жестко связаны как в /bin, так и в /usr/bin, все жесткие ссылки в /usr/binбудут перемещены в /bin.
Теперь вы можете подумать, что, поскольку /binи /usr/binнаходятся в $PATHпо умолчанию, а /binдоступен на /bootпо крайней мере до того, как будет смонтирован /usr, не должно иметь значения, является ли исполняемые файлы находятся в /binвместо /usr/bin.
Но это означает, что многие команды жестко запрограммировали пути к исполняемым файлам и ожидали, что они будут в каком-то конкретном случае. Обычный случай — она -челка. Все скрипты с:
#! /usr/bin/env bash
не будет работать после того, как вы сделаете mv /usr/bin/env /bin/env. В этом отношении наличие команд в обоих местах безопаснее, поскольку они не сломают эти сценарии.
Ваша установка должна быть в основном в порядке; не должно быть разных файлов с одинаковыми именами в
/usrи/usr/bin(, что соответствует вашему 2.1 ), поэтому наличие всех файлов в/binи/usr/binничего не сломает (, пока вы обновляете пакеты ). Единственная проблема, с которой вы можете столкнуться сейчас, это битые симлинки,если вы перезаписали бинарный файл символической ссылкой на него. Чтобы исправить это, ищите битые символические ссылки:find -L /bin /usr/bin -type l -lsи переустановите все пакеты, соответствующие перечисленным файлам (, например, если
/usr/bin/zshотображается как сломанный,dpkg -S /bin/zsh /usr/bin/zshсообщит вам, из какого пакета был получен файл; переустановите его с помощьюapt --reinstall install zsh).Вы можете отобразить и отсортировать по ctime файлы, которые были недавно изменены (, включая файлы, которые вы переместили):
ls -ltc /binЛучший способ отменить то, что вы сделали, — это использовать пакет
cruftи удалить файлы, которые он находит в/binили/usr/bin, которые не входят в пакет:sudo apt install cruft sudo cruft -d "/ /usr"если файлы не являются символическими ссылками на файлы в
/etc/alternatives(и в этом случае вы должны оставить их в покое ).
Может быть поучительно выяснить, почему ваша система в большей или меньшей степени «сломана».
- Как указывает @basile -starynkevitch, система управления пакетами может сильно запутаться, если найдет двоичные файлы в
/bin, хотя они должны быть в/usr/bin, и наоборот. - Некоторые (потенциально важные )сценарии могут быть жестко -подключены для поиска определенного двоичного файла в том или ином каталоге (в некоторых обстоятельствах это является хорошей практикой, например, с точки зрения безопасности, не полагаться на содержание
$PATH). - Причина, по которой существует различие между
/binи/usr/bin, заключается в том, что первый потенциально может находиться на разделе, который монтируется на более ранней стадии загрузки. В этом контексте (, то есть при загрузке системы ), не только/bin/xxxдвоичные файлы, вероятно, будут указаны полным путем, но и каталог/usr/binможет быть недоступен в системе в этот момент. (Если выdf /binиdf /usr/bin, вы можете увидеть в списке одну и ту же файловую систему или разные; вероятно, большинство установок по умолчанию в наши дни оставляют оба каталога в одном разделе ).
Таким образом, вы можете увидеть, что если у вас есть одинаковые двоичные файлы как в /bin, так и в /usr/bin, то проблемы 2 и 3 не возникнут, а ущерб от 1 может быть незначительным.. Re 1, например,пакеты могут быть удалены некорректно, если вы попытаетесь их удалить; и обновления могут быть искажены, если обновление пытается обновить копию в «правильном» месте, но игнорирует копию в «неправильном» месте. Таким образом, если приведенные выше меры кажутся слишком радикальными или сложными, вы можете уйти, оставив систему в таком состоянии.
Но если это важная система, я действительно не стал бы на это рассчитывать.
Общее правило (, снова вторящее @basile -starynkevitch )— никогда не баловаться с /usr/bin, /binи друзьями — они «принадлежат» к дистрибутиву — и пакет, который предлагает это делать как часть его обычной установки... не очень хороший пакет.
Редактировать:Относится к пункту 3, есть обсуждение в контексте systemd/Fedora и друзей о том, почему имеет смысл переместить все содержимое /binв /usr/bin, и символическая ссылка первого на второе. Это не рекомендация, что вы должны сделать это сами — эта страница адресована людям, которые занимаются распространением — но она включает в себя некоторую историю того, почему существует это различие (и, косвенно, почему теперь оно просто пыльная традиция ).