Вопрос или проблема
Я обновил Debian с версии 10 до 11 неделю назад.
Повторяющаяся ошибка:
ошибка поиска символа: /lib/systemd/libsystemd-shared-247.so: неопределённый символ: seccomp_api_get
Это вызвало панику ядра при загрузке системы.
Я был вынужден перейти на systemd как систему инициализации.
Теперь, когда я пытаюсь восстановить systemd, я получаю следующую ошибку:
root@nas:~# apt install systemd
Читаю списки пакетов... Готово
Строю дерево зависимостей... Готово
Читаю информацию о состоянии... Готово
systemd уже является самой новой версией (247.3-6).
0 обновлений, 0 новых установок, 0 для удаления и 0 не обновленных.
1 не полностью установлен или удален.
После этой операции будет использовано 0 Б дополнительного дискового пространства.
Хотите продолжить? [Y/n]
Настройка systemd (247.3-6) ...
systemd-machine-id-setup: ошибка поиска символа: /lib/systemd/libsystemd-shared-247.so: неопределённый символ: seccomp_api_get
dpkg: ошибка при обработке пакета systemd (--configure):
установочный скрипт пакета systemd вернул код завершения ошибки 127
Во время обработки были обнаружены ошибки:
systemd
needrestart пропускается, так как dpkg завершился с ошибкой
E: Подпроцесс /usr/bin/dpkg вернул код ошибки (1)
Мои версии:
root@nas:~# lsb_release -a
Нет доступных модулей LSB.
Идентификатор дистрибутора: Debian
Описание: Debian GNU/Linux 11 (bullseye)
Версия: 11
Кодовое имя: bullseye
root@nas:~# uname -a
Linux nas 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux
Я нашел решение здесь:
У меня была та же проблема. Причиной стали некоторые старые библиотеки в /lib/x86_64-linux-gnu, особенно libseccomp. Они не управляются пакетами (т.е. не принадлежат ни одному пакету). […]
Новый пакет libseccomp2 поставил новые бинарные файлы в /usr/lib/x86_64-linux-gnu, но загрузчик времени выполнения загружал старую версию в /lib/x86_64-linux-gnu. […]
Проблема исчезает, если я удаляю старые библиотеки из /lib/x86_64-linux-gnu
Поэтому я удалил эти файлы:
rm /lib/x86_64-linux-gnu/libseccomp.so.2*
И я смог вернуться к Systemd.
Как это проверить
Вы можете использовать dpkg --search, и он подскажет, если файл или каталог являются сиротами:
dpkg --search /lib/x86_64-linux-gnu/libseccomp.so.2
dpkg-query: путь, соответствующий шаблону /lib/x86_64-linux-gnu/libseccomp.so.2, не найден
Вы можете найти файлы без соответствующих пакетов с помощью cruft-ng: Как найти файлы, которые не принадлежат ни одному пакету?
Обновление
Существует символическая ссылка между /lib/x86_64-linux-gnu/ и /usr/lib/x86_64-linux-gnu/, поэтому ищите в обоих каталогах перед тем, как решиться что-то удалить.
Я выполнил dpkg --search /usr/lib/terminfo/ и это вернуло предупреждение, поэтому я удалил каталог, и это слегка сломало CLI, потому что на самом деле он является зависимостью ncurses-base.
Поиск в /usr/lib/ и /lib/ показывает пакет, который владеет этим каталогом.
dpkg --search /usr/lib/terminfo/ /lib/terminfo/
dpkg-query: путь, соответствующий шаблону /usr/lib/terminfo/, не найден
ncurses-base: /lib/terminfo
Поэтому мы не должны полагаться на один поиск с dpkg --search, чтобы решить, безопасно ли удалять данные.
Ответ или решение
Проблема, с которой вы столкнулись после обновления с Debian 10 на 11, связана с ошибкой, возникающей из-за несовместимости библиотек, особенно библиотеки libseccomp. Эта ошибка вызывает проблемы с инициализацией systemd и приводит к тому, что система не может загрузиться должным образом, что, в свою очередь, приводит к ядровому панике.
Причины ошибки
Сообщение об ошибке, которое вы видите:
symbol lookup error: /lib/systemd/libsystemd-shared-247.so: undefined symbol: seccomp_api_getуказывает на то, что исполняемый файл или библиотека пытается обратиться к символу, который не может быть найден в загруженной версии библиотеки. В данном случае, это означает, что systemd ссылается на старую или несовместимую версию libseccomp.
Во время вашего обновления система могла сохранить старые версии библиотек, которые не управляются пакетным менеджером (не принадлежат никакому пакету). Поэтому, даже после установки новой версии libseccomp, ваша система продолжала использовать старые версии библиотек, находящиеся в /lib/x86_64-linux-gnu.
Решение проблемы
Вы уже нашли частичное решение, заключающееся в удалении старых библиотек, что явилось правильным шагом:
rm /lib/x86_64-linux-gnu/libseccomp.so.2*Теперь система может распознавать только новые библиотеки, что разрешает конфликт при загрузке systemd.
Для более глубокого анализа, выполните следующие действия:
-
Проверьте наличие устаревших библиотек:
Используйте командуdpkg --search, чтобы увидеть, принадлежит ли библиотека какому-либо пакету. Например:dpkg --search /lib/x86_64-linux-gnu/libseccomp.so.2Если вы получите ответ
no path found matching pattern, это значит, что эта библиотека не принадлежит ни одному пакету. -
Поиск "сиротских" файлов:
Используйте утилитуcruft-ngдля поиска файлов, которые не принадлежат никакому пакету, чтобы убедиться, что нет других конфликтующих библиотек. -
Проверка ссылок:
Ваша система может иметь символическую ссылку между/lib/x86_64-linux-gnu/и/usr/lib/x86_64-linux-gnu/. Убедитесь, что вы проверяете обе директории перед удалением какой-либо библиотеки.
Методы оптимизации после обновления
После очищения системы от устаревших библиотек, разумно просмотреть остальные установленные пакеты на наличие зависимостей, которые могут быть повреждены:
-
Перезагрузите систему и проверьте, загружается ли
systemdкорректно. -
Обновите все установленные пакеты:
apt update apt upgrade -
Проверьте систему на наличие дополнительных проблем и ошибок, используя:
dpkg --configure -a -
Убедитесь, что у вас установлены все последние версии необходимых библиотек, включая
libseccomp.
Заключение
Следуя вышеперечисленным рекомендациям и тщательно управляя библиотеками, вы сможете устранить возникшие проблемы с systemd после обновления. Если после выполнения всех указанных действий проблема сохраняется, возможно, потребуется провести более детальный аудит вашей подсистемы пакетов или рассмотреть возможность обращения к сообществу поддержки Debian для получения дальнейшей помощи.