Беззастенчиво украдено у @cherdt с некоторыми улучшениями (предполагает оболочку типа zsh
или bash
с поддержкойksh
-вроде подстановки процессов):
f=filename; comm -12 <(cut -f1 < "$f" |sort) <(cut -f2 < "$f" | sort)
comm
читает из файлов, тогда как это stdout
перенаправление на временныйfd
Разве не должно быть /bin/bash
? Если нет, возможно, какой-то процесс использует нужные файлы, которые можно проверить с помощьюlsof
По рекомендации roaima я проверил (библиотеки общих объектов )системы Arch Linux, в которые хотел chroot
, особенно те, которые используются двоичным файлом bin/bash
. Они были сломаны; более конкретно, файлы размером 0 -/mnt/arch/lib64/ld-2.29.so
, /mnt/arch/usr/lib/libdl-2.29.so
и т. д.
Чтобы восстановить файлы внутри сломанного Arch Linux, я искал (в Интернете )имена файлов пакетов, в которых содержатся сломанные библиотеки. Эти файлы все еще находились в пакете менеджера пакетов. кэш, т.е. в
/mnt/arch/var/cache/pacman/pkg/glibc-2.29-3-x86_64.pkg.tar.xz
Я распаковал файл (еще до chroot
ing )вот так:
cd /mnt/arch
tar --wildcards -xvJf var/cache/pacman/pkg/glibc-2.29-3-x86_64.pkg.tar.xz usr/lib/\*
, который распаковал все файлы, соответствующие «usr/lib/*» из файла пакета.
После этого я действительно мог chroot
как задумано. Первое, что я сделал, это pacman -Syu
, чтобы завершить неудачное обновление.
Дополнительное примечание:Arch Linux использует BSD tar
для упаковки/распаковки файлов пакетов, а я использовал GNU tar
.Это может (обычно )иногда создавать проблемы, потому что GNU tar
не обрабатывает (распаковку и установку )специальных файловых атрибутов, которые BSDtar
(bsdtar
)сохраняет/устанавливает. Поскольку эти библиотечные файлы (, по-видимому, )не нуждаются в каких-либо атрибутах, я был в порядке.