Ошибка collisions systemd

Жди пока пофиксят баг в пакете, видимо его не тестировали перед публикацией.

Ну или для интереса посмотри чем отличаются перечисленные файлы (пакет же можно посмотреть не устанавливая на хост?)

«split/merge» тут ни при чём, он про симлинк usr/lib <-> usr/lib64 пишет, который и так и так был.

Нет в ебилде никаких багов. У меня стоит тот же sys-apps/systemd-253.3-r1 и файл /usr/lib64/systemd/libsystemd-core-253.so в одном экземпляре лежит там где надо.

У тебя /usr/lib и /usr/lib64 точно разные директории?
Если разные, то собери пакет с ключом -B и посмотри где у тебя эта сошка в пакете лежит. Поставить можно будет сразу, используя ключ -К, а перед установкой лишнюю из /usr/lib удалить, или лучше перенести, или переименовать, чтобы было что назад вернуть, если всё будет совсем плохо.

Переименовывал /usr/lib64/systemd, системд благополучно ставиться и в этой дире всего две либы

/usr/lib64/systemd/libsystemd-core-253.so*
/usr/lib64/systemd/libsystemd-shared-253.so*

и остального ничего нет.

Система при этом не грузиться

lrwxrwxrwx 1 root root 13 ноя 14  2020 /usr/lib64/systemd -> /lib/systemd//

Он является симлинком.

Одна и та же дира..

Чем джентушный OpenRC не угодил?

Перешел на него еще давно, гном тянул и много пакетов требовало системд.

/usr/lib64/systemd -> /lib/systemd

У меня не симлинк
ls -ld /usr/lib64/systemd
drwxr-xr-x 3 root root 4096 мая 5 17:34 /usr/lib64/systemd
И я про другие каталоги спрашивал, про /usr/lib и /usr/lib64

У тебя /lib симлинк на /usr/lib? А /usr/lib у тебя симлинк на /usr/lib64?

Переименовывал /usr/lib64/systemd

Зачем? Я предлагал переименовать, или куда-нибудь переместить .so файл.

ls -ld /bin /sbin /usr/sbin /lib /lib64 /usr/lib /usr/lib64
Покажи выхлоп этой команды

elogind не решает проблему с гономом?

ls -ld /lib
lrwxrwxrwx 1 root root 7 янв  1 14:19 /lib -> usr/lib/

ls -ld /usr/lib
drwxr-xr-x 100 root root 86016 мая 14 16:18 /usr/lib/

ls -ld /lib64
lrwxrwxrwx 1 root root 9 янв  1 14:19 /lib64 -> usr/lib64/

ls -ld /usr/lib64
drwxr-xr-x 137 root root 167936 мая 14 11:52 /usr/lib64/

Вот так с корневыми.

lrwxrwxrwx   1 root root      7 янв  1 14:19 /bin -> usr/bin/
lrwxrwxrwx   1 root root      7 янв  1 14:19 /lib -> usr/lib/
lrwxrwxrwx   1 root root      9 янв  1 14:19 /lib64 -> usr/lib64/
lrwxrwxrwx   1 root root      7 янв  1 14:19 /sbin -> usr/bin/
drwxr-xr-x 100 root root  86016 мая 14 16:18 /usr/lib/
drwxr-xr-x 137 root root 167936 мая 14 11:52 /usr/lib64/
lrwxrwxrwx   1 root root      3 янв  1 14:19 /usr/sbin -> bin/

Вот.

Здесь полный порядок.
Это тоже все каталоги?
ls -ld /usr/lib64 /usr/lib64/cryptsetup /usr/lib64/pkgconfig /usr/lib64/systemd /usr/lib/binfmt.d /usr/lib/environment.d /usr/lib/kernel /usr/lib/kernel/install.d /usr/lib/modprobe.d /usr/lib/modules-load.d /usr/lib/pam.d /usr/lib/rpm/macros.d /usr/lib/sysctl.d /usr/lib/systemd /usr/lib/sysusers.d /usr/lib/tmpfiles.d /usr/lib/udev /usr/lib/udev/hwdb.d /usr/lib/udev/rules.d

/usr/lib64/systemd и /usr/lib/systemd должны быть разные каталоги.
ls -l /lib64/systemd
итого 5248
-rwxr-xr-x 1 root root 2021504 мая 5 17:33 libsystemd-core-253.so
-rwxr-xr-x 1 root root 3344104 мая 5 17:33 libsystemd-shared-253.so
drwxr-xr-x 2 root root 4096 мая 8 18:58 system
Здесь всё верно, должно быть 2 сошки и один каталог
Все бинари должны лежать в /usr/lib/systemd и параметр ядра init=/usr/lib/systemd/systemd

ls -ld /usr/lib64 /usr/lib64/cryptsetup /usr/lib64/pkgconfig /usr/lib64/systemd /usr/lib/binfmt.d /usr/lib/environment.d /usr/lib/kernel /usr/lib/kernel/install.d /usr/lib/modprobe.d /usr/lib/modules-load.d /usr/lib/pam.d /usr/lib/rpm/macros.d /usr/lib/sysctl.d /usr/lib/systemd /usr/lib/sysusers.d /usr/lib/tmpfiles.d /usr/lib/udev /usr/lib/udev/hwdb.d /usr/lib/udev/rules.d
drwxr-xr-x 137 root root 167936 мая 14 11:52 /usr/lib64/
drwxr-xr-x   2 root root   4096 мая 13 16:06 /usr/lib64/cryptsetup/
drwxr-xr-x   2 root root  40960 мая 14 11:52 /usr/lib64/pkgconfig/
lrwxrwxrwx   1 root root     13 ноя 14  2020 /usr/lib64/systemd -> /lib/systemd//
drwxr-xr-x   2 root root   4096 янв  1 14:47 /usr/lib/binfmt.d/
drwxr-xr-x   2 root root   4096 янв  1 14:47 /usr/lib/environment.d/
drwxr-xr-x   3 root root   4096 янв  1 14:47 /usr/lib/kernel/
drwxr-xr-x   2 root root   4096 янв  1 14:47 /usr/lib/kernel/install.d/
drwxr-xr-x   2 root root   4096 мая 13 16:30 /usr/lib/modprobe.d/
drwxr-xr-x   2 root root   4096 янв  1 14:47 /usr/lib/modules-load.d/
drwxr-xr-x   2 root root   4096 янв  1 14:47 /usr/lib/pam.d/
drwxr-xr-x   2 root root   4096 янв  1 14:47 /usr/lib/rpm/macros.d/
drwxr-xr-x   2 root root   4096 мар  9 08:38 /usr/lib/sysctl.d/
drwxr-xr-x  17 root root   4096 мая 14 16:58 /usr/lib/systemd/
drwxr-xr-x   2 root root   4096 фев 18 10:17 /usr/lib/sysusers.d/
drwxr-xr-x   2 root root   4096 мая 13 18:23 /usr/lib/tmpfiles.d/
drwxr-xr-x   4 root root   4096 мая 13 15:49 /usr/lib/udev/
drwxr-xr-x   2 root root   4096 янв  1 14:47 /usr/lib/udev/hwdb.d/
drwxr-xr-x   2 root root   4096 мая 13 21:42 /usr/lib/udev/rules.d/

/usr/lib64/systemd и /usr/lib/systemd должны быть разные каталоги. А вот с этим проблема, это все один каталог и все ведет на /usr/lib/systemd

А параметр ядра

init=/lib/systemd/systemd

Вот такой.

А вот с этим проблема, это все один каталог и все ведет на /usr/lib/systemd

И поэтому не ставится?
А если удалить ссылку /usr/lib64/systemd, сделать каталог /usr/lib64/systemd и поставить systemd, то не грузится система?

Если сделать unlink на

/usr/lib64/systemd

То, все отлично ставиться и вроде-бы все хорошо, но вот дира

ls -l /lib64/systemd/
итого 4968
-rwxr-xr-x 1 root root 1939504 мая 14 17:18 libsystemd-core-253.so*
-rwxr-xr-x 1 root root 3135104 мая 14 17:18 libsystemd-shared-253.so*

Как выглядит.

каталога system нет в /usr/lib64/systemd

И само собой, после пересборки ядра и ребута система предлагает уйти в рескуе моде…

в одном экземпляре лежит там где надо.

И файла /usr/lib/systemd/libsystemd-core-253.so у тебя нет?

После того как изменил init в

/etc/default/grub 

Ничего не изменилось.

Следом сделал unlink на /usr/lib64/systemd

собрал и после пересобрал boot

• система не загрузилась.

Откатившись, сделал все тоже самое, только скопировал еще и

cp -R /usr/lib/systemd/system /usr/lib64/systemd/system 

и пересобрал груб конфиг (boot)

Система загрузилась и все нормально (вроде-бы)…

По итогу

/usr/lib/systemd/system

и 

/usr/lib64/systemd/system 

Должны как-то синхронизироваться или создать симлинк на

/usr/lib/systemd/system

или оставить так как есть сейчас?

Спасибо за помощь!

Нет, потому что он в /usr/lib64/systemd/
Там, на что ты отвечал, вроде всё ясно написано.

Есть, вот они.

ls -la /usr/lib/systemd/*.so
-rwxr-xr-x 1 root root 1643872 мая 14 15:56 /usr/lib/systemd/libsystemd-core-253.so*
-rwxr-xr-x 1 root root 2928028 мая 14 15:56 /usr/lib/systemd/libsystemd-shared-253.so*

Так тогда возвращаемся к вопросу, почему автору он пытается туда установиться, и отличающийся от своего клона в lib64?

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

Оставляю уже все как есть и дальше живу так!

Но, почему тогда каталог

/usr/lib64/systemd/system 

не захотел создаться автоматом или скопироваться?

А теперь то же в lib64 покажи?

Так, imul подсказал верно! После удаления симлинка - все инсталиться, только

/usr/lib64/systemd/system 

этот каталог не создается. Пришлось его руками скопировать с

/usr/lib/systemd/system 

и после этого все загрузилось.

ls -la /lib64/systemd/
итого 5160
drwxr-xr-x   3 root root    4096 мая 14 17:38 ./
drwxr-xr-x 138 root root  167936 мая 14 17:38 ../
-rwxr-xr-x   1 root root 1939504 мая 14 15:56 libsystemd-core-253.so*
-rwxr-xr-x   1 root root 3135104 мая 14 15:56 libsystemd-shared-253.so*
drwxr-xr-x  13 root root   20480 мая 14 17:38 system/

Вот.

Загрузиться то загрузилось, но это не исправление корня проблемы, а обходной маневр.

Корень проблемы в том что у тебя по две копии этих so, и разных - так не должно быть, скорее всего. У imul-а вот только по одному, как он говорит.

ls -la /usr/lib/systemd/*.so
-rwxr-xr-x 1 root root 1643872 мая 14 15:56 /usr/lib/systemd/libsystemd-core-253.so*
-rwxr-xr-x 1 root root 2928028 мая 14 15:56 /usr/lib/systemd/libsystemd-shared-253.so*
ls -la /lib64/systemd/*.so
-rwxr-xr-x   1 root root 1939504 мая 14 15:56 libsystemd-core-253.so*
-rwxr-xr-x   1 root root 3135104 мая 14 15:56 libsystemd-shared-253.so*

Сделай emerge -B sys-apps/systemd
У тебя появится готовый бинарный пакет в /usr/portage/packages/sys-apps/systemd
Посмотри его содержимое, что и куда раскладывается в системе.
Симлинков никаких не надо, почему у тебя не работают бинари из /usr/lib/systemd но работают из /usr/lib64/systemd я не знаю.
Была у тебя какая-то фигня, но при этом не ставился systemd, сейчас у тебя какая-то другая фигня, но теперь systemd ставится. Подозреваю, что дальше с обновлениями будет тоже не всё просто.
У меня все service файлы лежат в /usr/lib/systemd/system, /usr/lib64/systemd/system пустой. Может кто в тему ещё заглянет, подскажет.

ls -la /usr/lib/systemd/*.so
-rwxr-xr-x 1 root root 1643872 мая 14 15:56 /usr/lib/systemd/libsystemd-core-253.so*
-rwxr-xr-x 1 root root 2928028 мая 14 15:56 /usr/lib/systemd/libsystemd-shared-253.so*
 ls -la /lib64/systemd/*.so
-rwxr-xr-x 1 root root 1939504 мая 14 15:56 /lib64/systemd/libsystemd-core-253.so*
-rwxr-xr-x 1 root root 3135104 мая 14 15:56 /lib64/systemd/libsystemd-shared-253.so*
 file /usr/lib/systemd/libsystemd-core-253.so
/usr/lib/systemd/libsystemd-core-253.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
 file /usr/lib/systemd/libsystemd-shared-253.so
/usr/lib/systemd/libsystemd-shared-253.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
 file /lib64/systemd/libsystemd-core-253.so
/lib64/systemd/libsystemd-core-253.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
 file /lib64/systemd/libsystemd-shared-253.so
/lib64/systemd/libsystemd-shared-253.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped

Там 32 тут 64…

Да что ж такое, ты за всю тему не смог прочесть и понять стартовое сообщение? Там прямым текстом написано в чём проблема - в конфликте разных файлов за одно и то же имя.

Но нет, «какая-то фигня», «почему-то не работают», «теперь ставится» - как будто домохозяйка ситуацию описывает. Я думал гентушники склонны разбираться в сути происходящего у них на компе, а не вот это вот всё.

У автора был симлинк, поэтому всё что клалось в lib64 - появлялось и в lib, и наоборот. Удалив симлинк, он эффективно затёр всё то, что через него туда ставилось. (ту же директорию system). Потому и сломалось всё. Скопировал назад - починилось.

Потому что у каталогов /usr/lib64 и у /usr/lib теперь в дженте немного разное предназначение, не надо их содержимое смешивать.
Я честно не знаю, почему у него лежат сошки в /usr/lib/systemd, возможно это какие-то ошмётки от старых пакетов. Надо собирать пакет c -B, смотреть куда что рассовывается из него в систему и лишнее просто удалить.

почему у него лежат сошки в /usr/lib/systemd, возможно это какие-то ошмётки от старых пакетов

Да нет же! Читаем ещё раз!

 * Package 'sys-apps/systemd-253.3-r1' has internal collisions between
 * non-identical files (located in separate directories in the
 * installation image (${D}) corresponding to merged directories in the
 * target filesystem (${ROOT})):
 * 
 * 	/usr/lib/systemd/libsystemd-core-253.so
 * 		/usr/lib/systemd/libsystemd-core-253.so

Установка апдейта хочет записать этот файл! Он новый! И пакет именно тот же.

Да что ж такое, ты за всю тему не смог прочесть и понять стартовое сообщение?

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

Ну, наверно у тебя поддержка 32-бит где-то включена значит, хотя странно - почему раньше их тогда не было?

Ещё раз специально для тебя, сошек в этом каталоге быть не должно, симлинка быть не должно.
Эта проблема решилась, сейчас другая проблема у человека, почему система грузится с файлами service в /usr/lib64/systemd/system, хотя они должны лежать в /usr/lib/systemd/system.

Ну, наверно у тебя поддержка 32-бит где-то включена значит, хотя странно - почему раньше их тогда не было?

/etc/portage/make.conf 

ABI_X86="32 64"

Может быть из за этого?

сошек в этом каталоге быть не должно

Эта проблема решилась

ls -la /usr/lib/systemd/*.so
-rwxr-xr-x 1 root root 1643872 мая 14 15:56 /usr/lib/systemd/libsystemd-core-253.so*
-rwxr-xr-x 1 root root 2928028 мая 14 15:56 /usr/lib/systemd/libsystemd-shared-253.so*

Ага.

сейчас другая проблема у человека

Это всё одна проблема, и подозреваю что из-за включившегося как-то режима параллельной поддержки разных битностей (не знаю как он в генте называется), из-за чего lib и lib64 стали конфликтовать.

Выложи пожалуйста на pastebin выхлоп qlist sys-apps/systemd

А какая у него дата изменения?

Ещё может быть что оно и раньше так было, но при конвертации split->merge как-то 32-битные либы из /usr/lib молча затёрлись 64-битными (которые через симлинк установились в /lib, который тогда был другой директорией). По идее оно должно было ошибки написать а не делать так, так что тоже вряд ли.

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

при конвертации split->merge

Не, в /usr/lib/python-exec/python3.10/merge-usr указаны только такие каталоги

DIR_MAP = {
    "bin": "usr/bin",
    "sbin": "usr/bin",
    "usr/sbin": "usr/bin",
    "lib": "usr/lib",
    "lib32": "usr/lib32",
    "lib64": "usr/lib64",
    "libx32": "usr/libx32",
}

У него стоял симлинк /usr/lib64/systemd -> /lib/systemd, таким образом 64-битные либы системд оказывались в /lib/systemd.

32-битные либы системд сейчас установились в /usr/lib, а вот ставились ли раньше или нет - неизвестно. Если ставились, то им ничего не мешало: 32 в /usr/lib/systemd, 64 в /lib/systemd (симлинком из /usr/lib64/systemd). После merge-usr стало /lib/systemd = /usr/lib/systemd и вот этот конфликт с которого началась тема.

Единственное, что осталось непонятным, так это каким образом так вышло, что при мерже не было ошибок /lib vs /usr/lib - либо тогда в /usr/lib ещё не было 32-бит либ, либо merge-usr из тайком затёр и ничего не сообщил об этом.

Вот, пожалуйста.

https://pastebin.com/UbdudARW

Про -B уже не раз намекал.

я собрал сразу же и посмотрел, вот вывод.

https://pastebin.com/5NwnxmS0

Да, если бы /usr/lib64/systemd был каталогом, то проблемы с установкой не было бы. Или по третьему кругу будешь мне что-то доказывать?

либо merge-usr из тайком затёр и ничего не сообщил об этом

Это скрипт на питоне, его можно посмотреть. С какими каталогами он работает я уже писал выше.

Спасибо, теперь всё ясно. firkax совершенно прав насчёт смешивания 32 и 64 архитектуры. Симлинк заменён каталогом -> проблемы с установкой нет.
Насчёт /usr/lib/systemd/system — файлы service ставятся из пакета туда, там по идее и должны лежать и браться оттуда. У меня /usr/lib64/systemd/system пустой.
Используются service файлы просто. На них идут симлинки из /etc/systemd/system
Соответственно надо проверить например
ls -l /etc/systemd/system/multi-user.target.wants/
ls -l /etc/systemd/system/
в какой именно из каталогов идут ссылки на файлы service

Соответственно надо проверить например ls -l /etc/systemd/system/multi-user.target.wants/ ls -l /etc/systemd/system/ в какой именно из каталогов идут ссылки на файлы service

ls -l /etc/systemd/system/multi-user.target.wants/

итого 0
lrwxrwxrwx 1 root root 35 сен 15  2019 machines.target -> /lib/systemd/system/machines.target
lrwxrwxrwx 1 root root 46 мая 13 18:51 NetworkManager.service -> /usr/lib/systemd/system/NetworkManager.service
lrwxrwxrwx 1 root root 41 ноя 24  2020 open-vm-tools.service -> /lib/systemd/system/open-vm-tools.service
lrwxrwxrwx 1 root root 36 сен 15  2019 remote-fs.target -> /lib/systemd/system/remote-fs.target
lrwxrwxrwx 1 root root 44 июл 29  2021 systemd-resolved.service -> /lib/systemd/system/systemd-resolved.service
lrwxrwxrwx 1 root root 47 ноя 29  2020 vmvare-vmblock-fuse.service -> /lib/systemd/system/vmvare-vmblock-fuse.service


ls -l /etc/systemd/system/

итого 32
drwxr-xr-x 2 root root 4096 ноя 26 09:55 atftp.service.d/
lrwxrwxrwx 1 root root   57 мая 13 18:51 dbus-org.freedesktop.nm-dispatcher.service -> /usr/lib/systemd/system/NetworkManager-dispatcher.service
lrwxrwxrwx 1 root root   44 июл 29  2021 dbus-org.freedesktop.resolve1.service -> /lib/systemd/system/systemd-resolved.service
lrwxrwxrwx 1 root root   42 дек  8  2015 default.target -> /usr/lib64/systemd/system/graphical.target
lrwxrwxrwx 1 root root   35 мая 13 21:42 display-manager.service -> /usr/lib/systemd/system/gdm.service
drwxr-xr-x 2 root root 4096 сен 15  2019 getty.target.wants/
drwxr-xr-x 2 root root 4096 мая 14 19:16 multi-user.target.wants/
drwxr-xr-x 2 root root 4096 мая 13 18:51 network-online.target.wants/
drwxr-xr-x 2 root root 4096 фев 18 11:24 ntpdate.service.d/
drwxr-xr-x 2 root root 4096 мая 13 16:12 slapd.service.d/
drwxr-xr-x 2 root root 4096 фев 18 11:24 sntp.service.d/
-rw-r--r-- 1 root root  163 апр  6  2018 trezord.service

Только один он указывает на lib64

default.target -> /usr/lib64/systemd/system/graphical.target

default.target -> /usr/lib64/systemd/system/graphical.target

Меняй на default.target -> /usr/lib/systemd/system/graphical.target
Если загрузишься без проблем, то можно будет содержимое /usr/lib64/systemd/system грохнуть полностью и про всё забыть.
Ну и в остальных каталогах, имена которых заканчиваются на wants в /etc/systemd/system посмотри заодно. Исправляй ссылки в /usr/lib64/systemd/system на «без 64».

Спасибо!

sudo systemctl set-default graphical.target

По итогу gdm запускался из под 64, видать изначально ошибка была когда-то…

Пересоздало на /usr/lib/systemd/system

удалил все содержимое

/usr/lib64/systemd/system

и все заработало.

Спасибо Всем огромное за помощь! Благодарю! :))))))))))

Особо не за что.
Пометь тему как решённую.