ALT Linux Bugzilla – Full Text Bug Listing
|
Description
Leonid Krivoshein
2019-01-16 23:41:00 MSK
Created attachment 7946 [details]
Список установленных пакетов до начала обновления
Created attachment 7947 [details]
Список установленных пакетов по окончанию обновления
Надо выяснить, кто(почему) удаляет systemd. Бессмысленно предлагать логи без apt-get dist-upgrade -oDebug::pkgProblemResolver=1 Это всё равно, что выгружать дамп свопа. Свежеустановленный сервер в офисной установке тоже не перезагружается после обновления до текущего p8 (#35906) Created attachment 7949 [details]
apt-get dist-upgrade -oDebug::pkgProblemResolver=1
Проблема воспроизводится на Workstation в минимальной установке, логи приложил выше. Если установить пакет card-actions на свежеустановленную Workstation (в минимальной установке) перед dist-upgrade, то dist-upgrade проходит успешно и systemd не удаляется. На эту деталь тоже стоит обратить внимание: Если обновляться до архива p8 от 01.11.2018, а затем до текущего состояния p8, такого не происходит. (В ответ на комментарий №6) > Created an attachment (id=7949) [details] > apt-get dist-upgrade -oDebug::pkgProblemResolver=1 Видимо, мне уже нет смысла выгружать сюда то же самое. Ну или наоборот - если в установленной workstation удалить card-actions, то systemd начинает тоже выносить. Виной всему веса - нам нужно что бы как можно больше пакетов хотело systemd, тогда такого не будет происходить. (В ответ на комментарий №9) > Виной всему веса - нам нужно что бы как можно больше пакетов хотело systemd, > тогда такого не будет происходить. Есть основания полагать, что всему виной коммит, который надо срочно ревертить: http://git.altlinux.org/gears/C/ConsoleKit2.git?p=ConsoleKit2.git;a=commitdiff;h=adccab656e822fb686d3f66699a7b5856f36fc37 Вместо dist-upgrade достаточно сделать install systemd-utils, чтобы в этом убедиться. Но я всё равно не понимаю, почему, если обновляться в два приёма: до архива от 01.11.2018, затем до текущего состояния, этой проблемы не возникает. Если этот конфликт убрать, то будет файловый конфликт. Created attachment 7950 [details]
apt-get install -y -oDebug::pkgProblemResolver=1 systemd-utils
(В ответ на комментарий №10) > (В ответ на комментарий №9) > > Виной всему веса - нам нужно что бы как можно больше пакетов хотело systemd, > > тогда такого не будет происходить. > > Есть основания полагать, что всему виной коммит, который надо срочно ревертить: > http://git.altlinux.org/gears/C/ConsoleKit2.git?p=ConsoleKit2.git;a=commitdiff;h=adccab656e822fb686d3f66699a7b5856f36fc37 > > Вместо dist-upgrade достаточно сделать install systemd-utils, чтобы в этом > убедиться. Но я всё равно не понимаю, почему, если обновляться в два приёма: до > архива от 01.11.2018, затем до текущего состояния, этой проблемы не возникает. Этот коммит не просто так был сделан. На Workstation выносился systemd при dist-ugrade. А вся беда была в том, что я обновил версию ConsoleKit2. Проблему стопроцентно решит только откат версии ConsoleKi2 до той, что в workstation. Ещё можно попробовать убрать провайдес ConsoleKit у ConsoleKit2. Created attachment 7951 [details]
apt-get install -y -oDebug::pkgProblemResolver=1 systemd
...а если установить systemd, то он вынесет ConsoleKit2, после чего dist-upgrade проблем не создаёт.
Пробую без провайдесов ConsoleKit2 собрать в таске 219553 (В ответ на комментарий №15) > Пробую без провайдесов ConsoleKit2 собрать в таске 219553 Желательно без конфликтов с systemd-services. *** Bug 35906 has been marked as a duplicate of this bug. *** (In reply to comment #16) > (В ответ на комментарий №15) > > Пробую без провайдесов ConsoleKit2 собрать в таске 219553 > Желательно без конфликтов с systemd-services. И без конфликтов по файлам? (В ответ на комментарий №16) > (В ответ на комментарий №15) > > Пробую без провайдесов ConsoleKit2 собрать в таске 219553 > Желательно без конфликтов с systemd-services. Без них systemd выносился при обновлении 16.11.2018. ConsoleKit2 выносился пока у него не было версии для обновления. Как появилась, началась игра, кто больше весит. (В ответ на комментарий №18) > (In reply to comment #16) > > (В ответ на комментарий №15) > > > Пробую без провайдесов ConsoleKit2 собрать в таске 219553 > > Желательно без конфликтов с systemd-services. > > И без конфликтов по файлам? Конфликт уже давно есть у systemd-services. Выставив дополнительные конфликты я обошёл проблему 16.11.2018. Но, как оказалось, временно. Пробуйте: [#219553] p8 EPERM ConsoleKit2.git=1.2.1-alt2.M80P.3 > (В ответ на комментарий №15)
> Пробую без провайдесов ConsoleKit2 собрать в таске 219553
Сейчас тогда протестирую dist-uprade с этим таском...
(В ответ на комментарий №20) > Пробуйте: > > [#219553] p8 EPERM ConsoleKit2.git=1.2.1-alt2.M80P.3 Увы, но с подключенным таском проблема сохранилась: Следующие пакеты будут ЗАМЕНЕНЫ: altlinux-freedesktop-menu-mate (by mate-menus) efi-shell (by edk2-efi-shell) journalctl (by systemd-utils) libpytalloc (by python-module-talloc) libsystemd-shared (by systemd-utils) Следующие пакеты будут УДАЛЕНЫ: ConsoleKit2 ConsoleKit2-x11 bash-completion-journalctl bash-completion-systemd gutenprint-foomatic interactivesystem libqt5-egldeviceintegration openssh openssh-server systemd systemd-analyze systemd-services systemd-sysvinit vconsole-setup-kludge (В ответ на комментарий №22) > (В ответ на комментарий №20) > > Пробуйте: > > > > [#219553] p8 EPERM ConsoleKit2.git=1.2.1-alt2.M80P.3 > > Увы, но с подключенным таском проблема сохранилась: > > Следующие пакеты будут ЗАМЕНЕНЫ: > altlinux-freedesktop-menu-mate (by mate-menus) efi-shell (by edk2-efi-shell) > journalctl (by systemd-utils) > libpytalloc (by python-module-talloc) libsystemd-shared (by systemd-utils) > Следующие пакеты будут УДАЛЕНЫ: > ConsoleKit2 ConsoleKit2-x11 bash-completion-journalctl > bash-completion-systemd gutenprint-foomatic > interactivesystem libqt5-egldeviceintegration openssh openssh-server systemd > systemd-analyze systemd-services > systemd-sysvinit vconsole-setup-kludge ConsoleKit2 вынесся. А вот кому понадобился pam-ck-connector2? Может надо просто у systemd-services с pam-ck-connector2 выставить конфликт? Task #219553 try 2.1 с удалением конфликтов на services проблему тоже не решила. (В ответ на комментарий №24) > Task #219553 try 2.1 с удалением конфликтов на services проблему тоже не > решила. Сейчас добавлю конфликт на pam-ck-connector2 у systemd-services отдельным заданием и в этом же. Попробовать надо будет оба варианта. Тем временем проверьте, кто может хотеть pam-ck-connector2 Created attachment 7952 [details] Вторая попытка с таском #219553 тоже выносит systemd (В ответ на комментарий №26) > Тем временем проверьте, кто может хотеть pam-ck-connector2 pam-ck-connector2-1.2.1-alt2.M80P.3 pam-ck-connector2-debuginfo-1.2.1-alt2.M80P.3 Требует: <.p8.219553.200.2.1-pam-ck-connector2-1.2.1-alt2.M80P.3> pam-ck-connector2-1.2.1-alt2.M80P.3 autologin-1:1.0.0-alt7 Требует: <PAM(pam_ck_connector.so)> pam-ck-connector2-1.2.1-alt2.M80P.3 В apt'е алогоритм, основанный на весах. Если что-то удаляется, то это просто может значить, что его мало кто хочет в системе а в обновлении есть конфликтующий с ним пакет, который нужен большему количеству установленных приложений (как было с ConsoleKit2). Т.е. - можно просто добавить зависимостей на systemd у уже установленных пакетов и эта проблема временно рассосётся. (В ответ на комментарий №28) > Т.е. - можно просто добавить зависимостей на systemd у уже установленных > пакетов и эта проблема временно рассосётся. Эммм... а ничего надёжней придумать нельзя что ли? Можно пропатчить apt, это будет надёжнее. Но его не получится доставить до пользователя раньше, чем к нему (пользователю) попадёт обновление systemd. По идее можно ещё конфиг поправить apt'а, но с этим точно такая же проблема с доставкой. Можно ещё сделать какой-то пакет, который заобсолетит эти ConsoleKit* и не будет конфликтовать с systemd (пустышку). Но это приведёт к тому, что все реальные пользователи ConsoleKit будут страдать. (В ответ на комментарий №29) > Эммм... а ничего надёжней придумать нельзя что ли? Например, использовать apt-preferences на такие пакеты, как systemd. Вот только это должно было быть в декабрьском (2017) образе заложено. Сейчас сложно представить, как туда это подложить до dist-upgrade, не внося изменений в инструкцию по процедуре обновления. (В ответ на комментарий №29) > (В ответ на комментарий №28) > > Т.е. - можно просто добавить зависимостей на systemd у уже установленных > > пакетов и эта проблема временно рассосётся. > > Эммм... а ничего надёжней придумать нельзя что ли? Откатить версию ConsoleKit2 никак нельзя? Если не будет требоваться его обновление, то и проблемы не будет. уменьшить версию в репозитории нельзя. Попробуйте собрать systemd и ConsoleKit2 без взаимных конфликтов. (В ответ на комментарий №34) > Попробуйте собрать systemd и ConsoleKit2 без взаимных конфликтов. Вернёмся к тому с чего начали. systemd-services не уживается с ConsoleKit2 с тех пор как dbus починили, и ConsoleKit2 заработал. Created attachment 7953 [details] Третья попытка с таском #219553 тоже выносит systemd (В ответ на комментарий №25) > Сейчас добавлю конфликт на pam-ck-connector2 у systemd-services отдельным > заданием и в этом же. Попробовать надо будет оба варианта. Task #219553 3.1 тоже не дал результата. (( (В ответ на комментарий №35) > (В ответ на комментарий №34) > > Попробуйте собрать systemd и ConsoleKit2 без взаимных конфликтов. > > Вернёмся к тому с чего начали. systemd-services не уживается с ConsoleKit2 с > тех пор как dbus починили, и ConsoleKit2 заработал. Вопрос не уживания можно решить каким-то другим способом. выключить сервис в %post, например. (В ответ на комментарий №37) > (В ответ на комментарий №35) > > (В ответ на комментарий №34) > > > Попробуйте собрать systemd и ConsoleKit2 без взаимных конфликтов. > > > > Вернёмся к тому с чего начали. systemd-services не уживается с ConsoleKit2 с > > тех пор как dbus починили, и ConsoleKit2 заработал. > > Вопрос не уживания можно решить каким-то другим способом. выключить сервис в > %post, например. Сервис dbus'овский. Но мне пришла мысль. ConsoleKit2 не работает через dbus на sysvinit вроде, а только через xinitrc. А потому можно оторвать dbus'овский сервис, тогда они начнут уживаться, возможно. Предлагаю попробовать не затягивая. Речь о ALT Workstation 8.2 или 8.1? У 8.0 нет проблемы. Только что проверил. (В ответ на комментарий №39) > Предлагаю попробовать не затягивая. #219569 ещё собирается. (В ответ на комментарий №40) > Речь о ALT Workstation 8.2 или 8.1? У 8.0 нет проблемы. Только что проверил. 8.2, см. #1 (В ответ на комментарий №41) > #219569 ещё собирается. Спасибо, сейчас попробую... (В ответ на комментарий №41) > #219569 ещё собирается. Собралось и, похоже, проблему решило! Нет, я ошибался. ConsoleKit2 без сервисов dbus не работает. Created attachment 7955 [details] Таск #219569 (try 3.1) проблему решил (В ответ на комментарий №44) > Нет, я ошибался. ConsoleKit2 без сервисов dbus не работает. Что это означает? Таск решил проблему обновления! Created attachment 7956 [details]
Список установленных пакетов по окончанию обновления
(В ответ на комментарий №45) > Created an attachment (id=7955) [details] > Таск #219569 (try 3.1) проблему решил > > (В ответ на комментарий №44) > > Нет, я ошибался. ConsoleKit2 без сервисов dbus не работает. > > Что это означает? Таск решил проблему обновления! Ценой полной неработоспособности ConsoleKit2. С тем же успехом его можно и удалить. Сейчас пробую собрать, удалив лишь *.service файлы. Нужно у ConsoleKit2 _datadir/dbus-1/system-services/*.service положить куда-нибуть в конфиги, отключив по умолчанию. Например, в /etc/dbus-1/session.d копировать откуда-то из share в %post если есть такая необходимость (init не systemd). а в пакете /etc/dbus-1/session.d/мой сервис.service сделать как %ghost (В ответ на комментарий №48)
> Нужно у ConsoleKit2 _datadir/dbus-1/system-services/*.service положить
> куда-нибуть в конфиги, отключив по умолчанию.
> Например, в /etc/dbus-1/session.d копировать откуда-то из share в %post если
> есть такая необходимость (init не systemd).
> а в пакете
> /etc/dbus-1/session.d/мой сервис.service сделать как %ghost
Придётся так сделать. Не подскажете условие в %post для init?
(В ответ на комментарий №49) > (В ответ на комментарий №48) > > Нужно у ConsoleKit2 _datadir/dbus-1/system-services/*.service положить > > куда-нибуть в конфиги, отключив по умолчанию. > > Например, в /etc/dbus-1/session.d копировать откуда-то из share в %post если > > есть такая необходимость (init не systemd). > > а в пакете > > /etc/dbus-1/session.d/мой сервис.service сделать как %ghost > > Придётся так сделать. Не подскажете условие в %post для init? Хотя, чем так костылить, лучше в отдельный пакет вынести. Мешает только %_datadir/dbus-1/system-services/org.freedesktop.ConsoleKit.service ? Последняя сборка 219569 systemd не ломает? Created attachment 7957 [details] Таск #219569 (try 5.1) проблему также решил (В ответ на комментарий №50) > сборка 219569 systemd не ломает? Вроде нет и этот таск проблему также решает. (В ответ на комментарий №51) > Created an attachment (id=7957) [details] > Таск #219569 (try 5.1) проблему также решил > > (В ответ на комментарий №50) > > сборка 219569 systemd не ломает? > > Вроде нет и этот таск проблему также решает. Хорошо, новая итерация с субпакетом ConsoleKit2-service ожидает сборки. ConsoleKit2-service устанавливать не нужно. (В ответ на комментарий №52) > Хорошо, новая итерация с субпакетом ConsoleKit2-service ожидает сборки. > ConsoleKit2-service устанавливать не нужно. Что это значит? Имеет ли смысл получившееся задание начать тестировать в Обнинске? Или эксперимент ещё продолжается? (В ответ на комментарий №53) > Что это значит? На всякий... я ставлю так: apt-repo add #task apt-get update apt-get dist-upgrade и не использую apt-repo test для данного случая. (В ответ на комментарий №52) > Хорошо, новая итерация с субпакетом ConsoleKit2-service ожидает сборки. > ConsoleKit2-service устанавливать не нужно. По крайней мере, итерация 6.1 systemd не выносит и тоже решает проблему. (В ответ на комментарий №53) > (В ответ на комментарий №52) > > Хорошо, новая итерация с субпакетом ConsoleKit2-service ожидает сборки. > > ConsoleKit2-service устанавливать не нужно. > > Что это значит? > > Имеет ли смысл получившееся задание начать тестировать в Обнинске? > Или эксперимент ещё продолжается? Теперь эксперимент завершился. Нужно тщательно протестировать и пропустить в p8. Целевым пользователям ConsoleKi2 придётся устанавливать дополнительный пакет ConsoleKit2-service. П.с.: не дождался вчера, второй час ночи уже был у меня, уснул. А если всё-таки сделать проверку наличия systemd ? $ readlink /sbin/init ../lib/systemd/systemd Например так ? Я понимаю, что пользователей ConsoleKit2 не жалко, но всё-таки можно попробовать придумать необходимую обвязку. (В ответ на комментарий №57) > А если всё-таки сделать проверку наличия systemd ? > $ readlink /sbin/init > ../lib/systemd/systemd > > Например так ? > > Я понимаю, что пользователей ConsoleKit2 не жалко, но всё-таки можно > попробовать придумать необходимую обвязку. Сломаем миграцию с sysv на systemd, к примеру. Сей баг забудется, а люди будут гадать, почему не грузится система при миграции с sysv на systemd. А при миграции c systemd на sysv не заработает ConsoleKit, и люди опять должны гадать почему. Таких людей не жалко? Кроме того, поломка не смертельная. Без ConsoleKit2-service вернёмся на состояние до ноября 2018, когда я его починил в p8. Минимальные необходимые вещи для lxde-sysv он выполнял. Весь толк от ConsoleKit2-service - это работающая запоминалка уровня звука для ALSA. Больше ничего не поломается. polkit как не работал, так работать и не будет. polkit требуется собирать с ConsoleKit2, чтобы работал. m-p профили поправлю. В lxde-sysv добавлю зависимость на ConsoleKit2-service. Так что пользователи lxde-sysv стартеркита не пострадают. Пострадают пользователи стартеркита xfce-sysv, но я на форуме напишу, потери будут минимальными. icewm вообще ConsoleKit2 не нужен похоже. Антон, спасибо. Всё понятно. Ждём результатов тестирования этого задания в p8. Created attachment 7959 [details]
Предложение обновления после правки pkgpriorities
Ещё один эксперимент, пока задание не пропустили. Вот как предлагается решать на уровне системы, профилей и APT'а. То, о чём я говорил в списке рассылки в прошлом году. Здесь я добавил в секцию Important: interactivesystem и systemd, после чего огрёб приложенное...
Created attachment 7960 [details]
Ещё один вариант выноса всей системы
Так даже интереснее! При /etc/apt/pkgpriorities:
Important:
basesystem
interactivesystem
etcnet
Required:
apt
systemd
mate-file-manager
openssh-server
NetworkManager
Standard:
gnome-screensaver
kernel-doc
libpam0
libpam0-devel
maxima-bin-gcl
metacity-gnome
postfix
python-dev
python-modules-tkinter
xscreensaver-hacks
Похоже apt не может справиться с ситуацией, когда обновления требуют два пакета, которые стали в новых версиях между собой конфликтовать. А если указать в important только systemd-services? почему не может справиться ? он как раз справляется - считает что удалить нужно тот, на который меньше зависимостей у установленных пакетов. (В ответ на комментарий №63) > почему не может справиться ? он как раз справляется - считает что удалить нужно > тот, на который меньше зависимостей у установленных пакетов. Так он выносит обе стороны конфликта. И это мне странно. Хоть бы на какую-то сторону встал. Например, если указан пакет как важный, то пусть встаёт на его сторону в конфликте? Но он же всех выносит. (В ответ на комментарий №62)
> А если указать в important только systemd-services?
Могу попробовать, но это нечестно и поэтому не имеет смысла. В этом файле указываются реперные точки графа, то есть заранее неизвестно, что повлияет в будущем на граф, но известно, что не должно меняться в системе совершенно точно.
Наверное, нужно менять APT в части dist-upgrade -- после обновления rpm, apt-conf-*, apt и их зависимостей только новый apt с новым конфигом должен принимать решение о транзакции. Но это скорее дискуссия для devel@.
(В ответ на комментарий №62)
> А если указать в important только systemd-services?
С другой стороны, если граф меняется значительно, в сравнении с первоначальным, и apt будет предусматривать возможность обновления сначала именно apt-conf-*, тогда да, такое изменение в /etc/apt/pkgpriorities будет не просто иметь смысл, а должно стать частью процедуры dist-upgrade и в этом случае результат представляет интерес. Вот он:
Следующие пакеты будут ЗАМЕНЕНЫ:
altlinux-freedesktop-menu-mate (by mate-menus) bash-completion-journalctl (by bash-completion-systemd)
efi-shell (by edk2-efi-shell) journalctl (by systemd-utils) libpytalloc (by python-module-talloc)
libsystemd-shared (by systemd-utils)
Следующие пакеты будут УДАЛЕНЫ:
ConsoleKit2 ConsoleKit2-x11 gutenprint-foomatic libqt5-egldeviceintegration
(В ответ на комментарий №64) > Так он выносит обе стороны конфликта. И это мне странно. Хоть бы на какую-то > сторону встал. Например, если указан пакет как важный, то пусть встаёт на его > сторону в конфликте? Но он же всех выносит. apt.git (ориентируюсь на Сизиф, поскольку речь о p9) объясняет это поведение, а также полностью подтверждает мою теорию о том, что зря мы не используем по назначению /etc/apt/pkgpriorites, вынесенный в отдельный пакет apt-conf-sisyspus (apt-conf-branch). Кстати, поступило предложение перенести его в branding-*-release -- это опорный пакет любого решения. apt/apt-pkg/rpm/rpmpackagedata.cc (RPMPackageData::RPMPackageData) не в самом начале конструктора есть разблюдовка секций на числовые значения приоритетов и флагов. Как можно заметить, в исходном APT'е (и конфиге rpmpriorities) самыми важными являются пакеты Essential, но в нашем конфиге даже нет такой секции. Это ещё "круче", чем Important и Required. apt/apt-pkg/algorithms.cc (pkgDistUpgrade и pkgProblemResolver::MakeScores) -- здесь всё основное и по тому, как рассчитываются коэффициенты при конфликтах (разумеется, относительно pkgpriorites), и сам алгоритм dist-upgrade, выполняемый над кэшем в несколько последовательных шагов, начиная с (sic!) уже установленных пакетов, а не так, как хотелось бы, при этом Essential-пакеты идут лишь на третьем шаге и в самом конце фиксятся конфликты по коэффициентам. Сейчас в p8 обновления проходят нормально. |
