Created attachment 7945 [details] Журнал выполнения apt-get dist-upgrade -y После обновления свежеустановленной системы ALT Рабочая станция 8 в минимальной комплектации до текущего p8, компьютер не может перезагружаться и выключаться, dist-upgrade выносит systemd. Если же обновляться до архива p8 от 01.11.2018, а затем до текущего состояния p8, такого не происходит. Проблема затрагивает физические машины заказчиков, также проверялось мною и АЛП в виртуалках. Воспроизвожу в виртуалке, запущенной следующим образом: $ qemu-img create -f qcow2 -o size=100G $TMPDIR/p8ws.img $ /usr/bin/qemu-system-x86_64 -no-user-config -nodefaults \ -name P8WS -machine type=q35,accel=kvm -enable-kvm \ -cpu kvm64 -smp sockets=1,cores=4 \ -m 1G,slots=4,maxmem=4G -balloon virtio \ -drive if=none,id=drive0,discard=ignore,aio=threads,format=qcow2,file="$TMPDIR/p8ws.img" \ -device virtio-blk-pci,drive=drive0,scsi=off,write-cache=off \ -cdrom "$HOME/iso/alt-workstation-8.2-20171225-x86_64.iso" \ -soundhw hda,pcspk -vga virtio -netdev user,id=net0,restrict=no \ -device virtio-net,netdev=net0,id=eth0 \ -fsdev local,security_model=none,id=fsdev0,path="$TMPDIR" \ -device virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=exchange \ -rtc base=localtime,clock=host,driftfix=slew -usb -device usb-tablet \ -sdl -ctrl-grab -no-fd-bootchk Затем ставлю Альт Рабочая станция 8 штатным образом, всё по дефолту, сняв галочки по всему дополнительному ПО, то есть для воспроизведения минимальная установка обязательна. Далее: $ uname -a Linux host-15.localdomain 4.9.71-std-def-alt0.M80P.1 #1 SMP Thu Dec 21 01:27:05 UTC 2017 x86_64 GNU/Linux $ su- # apt-get update # apt-get dist-upgrade -y Концовка процесса обновления при этом выглядит так: warning: /etc/openssh/sshd_config saved as /etc/openssh/sshd_config.rpmsave warning: /etc/systemd/journald.conf saved as /etc/systemd/journald.conf.rpmsave Running /usr/lib/rpm/posttrans-filetriggers telinit: timeout opening/writing control channel /dev/initctl Завершено. начинается перестройка базы данных /var/lib/rpm перестройка базы данных /var/lib/rpm завершена # l $(which poweroff) lrwxrwxrwx 1 root root 4 янв 16 18:37 /sbin/poweroff -> halt # l $(which halt) -rwxr-xr-x 1 root root 18856 фев 19 2015 /sbin/halt # poweroff Broadcast message from root@host-15.localdomain (pts/0) (2019-01-16 18:43:56): The system is going down for system halt NOW! shutdown: timeout opening/writing control channel /dev/initctl init: timeout opening/writing control channel /dev/initctl По журналу обновления видно, что кто-то выносит systemd и intractivesystem, ставит sysvinit, само обновление приводит к тому, что компьютер нельзя ни выключить, ни перезагрузить. Помогает только такой вызов: echo o > /proc/sysrq-trigger Под подозрением apt, rpm, systmemd, но это может быть кто угодно.
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 обновления проходят нормально.
