Вопросы Теги

Размонтирование /usr с внешнего диска [закрыто]

Когда apt-get решает удалить пакет как часть установки другого пакета, это связано с объявленным конфликтом (который может не отражать фактический конфликт). Пакеты без мультиархитектуры конфликтуют с одним и тем же пакетом из другой архитектуры; как объяснено в ответе на Почему попытка установки 64-битной библиотеки через apt грозит удалением ряда требуемых 32-битных библиотек? Это часто случается с пакетами разработки.

Тем не менее, вы можете принудительно установить конфликтующий пакет, используя dpkg --force-sizes . Вам нужно будет загрузить затронутые пакеты и установить их вручную, и вы не сможете использовать apt-get , пока конфликт не будет разрешен (или, скорее, apt-get будет настаивать на разрешении конфликта). Вы можете сломать пакеты, вовлеченные в конфликт, но, по крайней мере, вы можете попробовать ...

Я не знаю, как отключить обработку конфликтов apt-get .

Альтернативой является исправление уязвимых пакетов; в большинстве случаев это достаточно просто и позволит избежать любых последующих проблем с apt . Например, для harfbuzz в Debian 8:

  • загрузите исходный код и извлеките его: 

     dget http://httpredir.debian.org/debian/pool/main/h/harfbuzz/ harfbuzz_0.9.35-2.dsc 
cd harfbuzz-0.9.35

  • отредактируйте debian / control и добавьте Multi-Arch: то же самое после строки Architecture в разделе Пакет: libharfbuzz- dev

  • добавьте запись в журнал изменений, чтобы ваши пользовательские пакеты не были заменены текущей версией из архива: 

     dch -n "Включить Multi-Arch в пакете -dev."

  • скомпилируйте пакет (вам нужно будет сделать это на компоновщике amd64 и компоновщике i386 - здесь pbuilder или sbuild ) 

     dpkg-buildpackage -us -uc

Это создаст совместно устанавливаемые пакеты libharfbuzz-dev . Это работает, потому что пакеты уже можно было установить совместно, им просто не хватало необходимых метаданных. Для harfbuzz это было исправлено в Debian 9.

1
03.02.2019, 17:13
1 ответ

Используйте связанное монтирование /, чтобы сделать оригинал /usr(, который, вероятно, должен быть пустым, если /usrбыл смонтирован поверх него до того, как /usrбыл когда-либо заполнен ), и скопируйте смонтированный /usrнад ним. 

# mkdir /root/underlyingroot
# mount --bind --make-private / /root/underlyingroot
# cp -ax /usr /root/underlyingroot
# umount /root/underlyingroot

--make-privateпредназначен для отмены случая, когда /монтируется с опциейshared, что при работеsystemd. В противном случае все, что смонтировано (, например :автоматическое монтирование вставленного устройства и т. д. )между mountи umountвыше, будет отражено внутри /root/underlyingrootи помешает простой umount /root/underlyingrootработе после.

Теперь, когда копирование завершено, вы можете отредактировать /etc/fstabи удалить точку монтирования /usr.

Если вообще ничего не используется /usr, вы также можете umountнемедленно /usrи закончить. Но в настоящее время трудно заставить все работать без использования /usr, если не в однопользовательском режиме или режиме восстановления, а сегодня даже даже не всегда (, например, в более новой CentOS ), поэтому перезагрузка, вероятно, потребуется в любом случае. Вы также можете рассмотреть umount --lazy /usr, что позволит немедленно избавиться от /usrи выполнять любые новые обновления /usrво внутренней памяти, а не во внешней, но внешняя все равно потребуется до следующей перезагрузки.

1
27.01.2020, 23:42

Теги

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