(gelöst) Schwierigkeiten beim Upgrade auf buster ohne systemd

[guennid]

consolekit gibt's nicht mehr in buster, damit kein pavucotrol, damit kein bluetooth (ohne systemd). Ich muss mal schauen, ob sich mit den bluez-alsa-(oder umgekehrt)Sachen aus der Raspian-Ecke was hinbiegen lässt.

Grüße, Günther

[Blackbox]

consolekit gibt's nicht mehr in buster, damit kein pavucotrol, damit kein bluetooth (ohne systemd).

Hallo Günther,

das ging bereits mit Stretch nur mit Bodengymnastik bzw. verursachte Probleme wegen fehlender Abhängigkeiten.
Bei mir war es ein Hängenbleiben nach dem Reboot.
Kam zum Glück nicht zu oft vor, aber wenn ein Kernelupdate fällig war, ist es verlässlich nicht durchgestartet.

Sollte es dir wie den meisten Nutzern bei pavucotrol nur um den Lautstärkeregler gehen, dann schau dir einmal volumeicon-alsa an.

Ich muss mal schauen, ob sich mit den bluez-alsa-(oder umgekehrt)Sachen aus der Raspian-Ecke was hinbiegen lässt.

Weiterhin frage ich mich, warum du ein FrankenDebian bauen möchtest, anstatt ein Devuan einzusetzen?

[guennid]

das ging bereits mit Stretch nur mit Bodengymnastik bzw. verursachte Probleme wegen fehlender Abhängigkeiten.

Falls du damit bluetooth meinst - und um bluetooth geht's mir: Das läuft hier unter stretch ohne systemd umständlich, aber problemlos.

frage ich mich, warum du ein FrankenDebian bauen möchtest

Die Installation EINES Fremdpaketes, ohne irgendwelche Fremdabhängigkeiten möchte ich eigentlich noch nicht als FrankenDebian bezeichnen.

Grüße, Günther

[Blackbox]

Mein Edit kam zu spät.

[guennid]

Um die Lautstärkeregelung ging's nie. Es ging um Lautsprecherauswahl.
Aber ich hab's nochmal geprüft. Du hast insofern recht, als dass man pulseaudio-module-bluetooth und damit bluetooth in buster auch ohne systemd betreiben könnte. Ob das dann im Endeffekt ohne pavucontrol performanter wäre, als auf PA zu verzichten und bluealsa-*_i386/amd64.deb zu benutzen, lasse ich mal dahingestellt sein. Insbesondere, weil ich nicht weiß, wie nötig dann vielleicht doch das empfohlene libpam-systemd für bluetooth wäre, womit wir dann letztlich doch wieder bei systemd gelandet wären.

Was devuan betrifft: Das verfolge ich sehr wohl. Beowulf ohne systemd zu releasen scheint Devuan beträchtliche Schwierigkeiten zu bereiten. Und insofern fragt sich, ob sich das halten kann, ohne die kommerziell genutzte manpower von RedHat im Hintergrund, auf die Debian sich momentan stützt.

Grüße, Günther

[guennid]

Hmm, gibt es bei buster etwa einen Unterschied zwischen i386 und amd64? Beim gerade laufenden dist-upgrade von stretch nach buster auf einer amd64-Maschine ist pavucontrol installiert. sysvinit-core fliegt nicht raus und wird nicht durch systemd ersetzt.

Bei meiner o.a. Simulation, pavucontrol in ein laufendes buster auf einer i386-Maschine zu installieren, war genau das der Fall.

Grüße, Günther

[Blackbox]

Hmm, gibt es bei buster etwa einen Unterschied zwischen i386 und amd64? Beim gerade laufenden dist-upgrade von stretch nach buster auf einer amd64-Maschine ist pavucontrol installiert. sysvinit-core fliegt nicht raus und wird nicht durch systemd ersetzt.

Kann ich mir fast nicht vorstellen, dass die Maintainer einen Extra-Aufwand betreiben, aber ich könnte mir vorstellen dass du eine andere Paketauswahl auf dem 32 Bit System getroffen hast?
Vielleicht hast du unbewusst auf Metapakete verzichtet, die in deinem 64 Bit System für Trouble sorgen?

Bei meiner o.a. Simulation, pavucontrol in ein laufendes buster auf einer i386-Maschine zu installieren, war genau das der Fall.

Ich würde (wahrscheinlich) in diesem Fall alle Pakete auf beiden Systemen vergleichen um die Differenzen zu sehen?

[guennid]

Vielleicht hast du unbewusst auf Metapakete verzichtet, die in deinem 64 Bit System für Trouble sorgen?

die „troubles“ macht das 32 Bit System, nicht das 64er. Die Paketauswahl ist sicherlich unterschiedlich. Das 32 Bit System ist eigentlich ausgemustert und dient(e) lediglich als schmales Testsystem, um zu schauen, was beim dist-upgrade geht und was nicht.

Ich würde (wahrscheinlich) in diesem Fall alle Pakete auf beiden Systemen vergleichen um die Differenzen zu sehen?

Mal abgesehen davon, dass das sehr viel Aufwand ist, fühle ich mich kaum in der Lage, aus dem Vergleich belastbare Schlüsse für den gegebenen Fall zu ziehen, und ich vermag mir eigentlich auch gar nicht vorzustellen, dass Pakete, die mit sound gar nichts zu tun haben, bewirken sollen, dass für bluetooth beim gleichen Release jeweils ein anderes Init-System benötigt wird (wobei man systemd kaum noch als Init-System bezeichnen kann). Ergo werde ich das bei meinem jetzigen Kenntnisstand nicht tun.

Nochmal: das jetzt auf buster hochgezogene 64er System hat alsa-utils, alsa-oss, pulseaudio-module-bluetooth und pavucontrol - und sysvinit-core (und openrc). Versuche ich alsa-utils alsa-oss, pulseaudio-module-bluetooth und pavucontrol in das buster-System des 32er Systems zu installieren, fliegt sysvinit-core raus und systemd rein.

Grüße, Günther

[smutbert]

Mal abgesehen davon, dass das sehr viel Aufwand ist, fühle ich mich kaum in der Lage, aus dem Vergleich belastbare Schlüsse für den gegebenen Fall zu ziehen, und ich vermag mir eigentlich auch gar nicht vorzustellen, dass Pakete, die mit sound gar nichts zu tun haben, bewirken sollen, dass für bluetooth beim gleichen Release jeweils ein anderes Init-System benötigt wird [...]

Wenn du der Sache auf den Grund gehen willst, würde ich empfehlen so an die Sache heranzugehen - ob dir das zu viel Aufwand ist, musst du sagen.
Interessant sind wahrscheinlich vor allem die manuell installierten Pakete:

Code: Alles auswählen

$ apt-mark showmanual > manuell_64bit.txt

und am anderen System

Code: Alles auswählen

$ apt-mark showmanuell > manuell_32bit.txt

dann kopierst du die beiden Textdateien in ein Verzeichnis auf einem Computer und vergleichst sie

Code: Alles auswählen

$ comm -2 -3 manuell_64bit.txt manuell_32bit.txt

zeigt nur die Pakete an, die auf dem 64 Bit System als manuell installiert markiert sind, während

Code: Alles auswählen

$ comm -1 -3 manuell_64bit.txt manuell_32bit.txt

nur die Pakete auflistet, die nur auf dem 32-Bit System manuell installiert sind. Automatische installierte Pakete sind wahrscheinlich eher nicht schuld, aber die könntest du gleichermaßen vergleichen, mit showauto statt showmanual.
Die Paketlisten, die die comm-Befehle ausgeben könntest du dann posten und am besten auch die Ausgabe/Nachfrage von apt, wenn du versuchst pavucontrol zu installieren.

Unterschiede zwischen amd64 und i386 als Ursache würde ich genauso wie Blackbox ausschließen.

[Blackbox]

Die Paketauswahl ist sicherlich unterschiedlich.

Bitte nicht falsch verstehen, aber wie kannst du ein System als Testsystem verstehen, welches (wahrscheinlich) eine unterschiedliche Paketauswahl besitzt?

Mal abgesehen davon, dass das sehr viel Aufwand ist, fühle ich mich kaum in der Lage, aus dem Vergleich belastbare Schlüsse für den gegebenen Fall zu ziehen, und ich vermag mir eigentlich auch gar nicht vorzustellen, dass Pakete, die mit sound gar nichts zu tun haben, bewirken sollen, dass für bluetooth beim gleichen Release jeweils ein anderes Init-System benötigt wird (wobei man systemd kaum noch als Init-System bezeichnen kann). Ergo werde ich das bei meinem jetzigen Kenntnisstand nicht tun.

Eigentlich™ ist das nicht viel Aufwand.

Auf beiden Systemen mit Hilfe von dpkg die installierten auslesen.

Code: Alles auswählen

dpkg -l > Pakete_32bit

bzw.

Code: Alles auswählen

dpkg -l > Pakete_64bit

und sie erzeugten Dateien danach mit diff vergleichen.

Code: Alles auswählen

diff -y Pakete_32bit Pakete_64bit

Nochmal: das jetzt auf buster hochgezogene 64er System hat alsa-utils, alsa-oss, pulseaudio-module-bluetooth und pavucontrol - und sysvinit-core (und openrc). Versuche ich alsa-utils alsa-oss, pulseaudio-module-bluetooth und pavucontrol in das buster-System des 32er Systems zu installieren, fliegt sysvinit-core raus und systemd rein.

Verzeihung, mein Fehler, ich habe tatsächlich die Systeme verwechselt.

//Edit: Der Lösungsansatz von smutbert klingt ebenfalls interessant.

Unterschiede zwischen amd64 und i386 als Ursache würde ich genauso wie Blackbox ausschließen.

Ein kleines Missverständnis liegt hier doch vor, denn ich halte die unterschiedliche Paketauswahl für ausschlaggebend.
Bin gespannt wessen Vermutung eintrifft.

[guennid]

Tut mir leid, Leute mir ist das zuviel Aufwand mit ungewissem Ausgang und fehlender praktischer Relevanz. Auf dem 64er System existiert das Problem nicht, das 32er Test-System nutze ich nicht wirklich, und falls ich doch mal in die Verlegenheit kommen sollte, weiß ich ja dank smutbert, wie ich bluetooth auch ohne pavucontrol und pulse unter Buster betreiben kann.

Ich würde mir antun nachzuforschen, wenn ihr 'ne konkrete Vermutung hättet, was für die systemd-Forderung auf dem 32er System verantwortlich sein könnte.

Grüße, Günther

[Blackbox]

Ich würde mir antun nachzuforschen, wenn ihr 'ne konkrete Vermutung hättet, was für die systemd-Forderung auf dem 32er System verantwortlich sein könnte.

Dazu müsste ich die Unterschiede auf beiden Systemen kennen, deswegen wäre es nützlich, wenn du das Ergebnis von dem von mir vorgeschlagenen Weg posten könntest.
Alles andere ist sonst im trüben Nebel herumirren.

Ich kann aber auch gut damit leben, wenn du keinen Bock darauf hast.

[guennid]

Also gut, ich fang mal mit den manuellen an. comm funktioniert nicht. Die Vergleichsdateien sind nicht sortiert.

edit:
Sortiert habe ich mit sort -o
So, hier habt ihr den Kram:

pastebin/?mode=view&s=40884
pastebin/?mode=view&s=40885

buster-Standard-Kern 4.19:

Code: Alles auswählen

# apt-get -s install pavucontrol
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
  adwaita-icon-theme dbus dbus-user-session dconf-gsettings-backend dconf-service glib-networking glib-networking-common
  glib-networking-services gsettings-desktop-schemas libapparmor1 libargon2-1 libasound2 libasound2-data libasyncns0 libatk-bridge2.0-0
  libatspi2.0-0 libcairo-gobject2 libcanberra-gtk3-0 libcanberra0 libcolord2 libcryptsetup12 libdconf1 libflac8 libgtk-3-0 libgtk-3-common
  libgtkmm-3.0-1v5 libidn11 libjson-c3 libjson-glib-1.0-0 libjson-glib-1.0-common liblcms2-2 libltdl7 libogg0 libpam-systemd libproxy1v5
  libpulse-mainloop-glib0 libpulse0 librest-0.7-0 libsndfile1 libsoup-gnome2.4-1 libsoup2.4-1 libtdb1 libvorbis0a libvorbisenc2 libvorbisfile3
  libwayland-cursor0 libwayland-egl1 libxkbcommon0 libxtst6 sound-theme-freedesktop systemd systemd-sysv
Vorgeschlagene Pakete:
  libasound2-plugins alsa-utils libcanberra-gtk0 libcanberra-pulse colord gvfs liblcms2-utils pulseaudio systemd-container policykit-1
Empfohlene Pakete:
  at-spi2-core libcanberra-gtk3-module libgtk-3-bin pulseaudio libnss-systemd
Die folgenden Pakete werden ENTFERNT:
  sysvinit-core
Die folgenden NEUEN Pakete werden installiert:
  adwaita-icon-theme dbus dbus-user-session dconf-gsettings-backend dconf-service glib-networking glib-networking-common
  glib-networking-services gsettings-desktop-schemas libapparmor1 libargon2-1 libasound2 libasound2-data libasyncns0 libatk-bridge2.0-0
  libatspi2.0-0 libcairo-gobject2 libcanberra-gtk3-0 libcanberra0 libcolord2 libcryptsetup12 libdconf1 libflac8 libgtk-3-0 libgtk-3-common
  libgtkmm-3.0-1v5 libidn11 libjson-c3 libjson-glib-1.0-0 libjson-glib-1.0-common liblcms2-2 libltdl7 libogg0 libpam-systemd libproxy1v5
  libpulse-mainloop-glib0 libpulse0 librest-0.7-0 libsndfile1 libsoup-gnome2.4-1 libsoup2.4-1 libtdb1 libvorbis0a libvorbisenc2 libvorbisfile3
  libwayland-cursor0 libwayland-egl1 libxkbcommon0 libxtst6 pavucontrol sound-theme-freedesktop systemd systemd-sysv
0 aktualisiert, 53 neu installiert, 1 zu entfernen und 0 nicht aktualisiert.

Grüße, Günther

[smutbert]

Ein Anhaltspunkt ist vermutlich die geplante Installation von dbus-user-session, das von libpam-systemd abhängt und die Tatsache, dass auf dem amd64-System einige Pakete (manuell) installiert sind:
- sysvinit
- sysv-rc
wohingegen am 32bittigen System openrc installiert ist. Verwendest du auf dem 32Bit-System openrc (das kann ja nicht gleichzeitig mit sysv-rc installiert sein)?

[guennid]

Ja, auf dem 32er System ist openrc installiert - eine etwas aparte Vorstellung, dass ausgerechnet openrc bei der Installation von pavucontrol systemd nach sich zieht. Andererseits, so sieht's aus, wenn ich openrc auf dem 64bit-System installierte:

Code: Alles auswählen

# apt-get -s install openrc
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
  libeinfo1 librc1
Vorgeschlagene Pakete:
  policycoreutils
Die folgenden Pakete werden ENTFERNT:
  rcconf sysv-rc
Die folgenden NEUEN Pakete werden installiert:
  libeinfo1 librc1 openrc

pavucontrol wird davon offenbar nicht berührt.

Grüße, Günther

[JTH]

Code: Alles auswählen

# apt-get -s install pavucontrol
[…]
Die folgenden zusätzlichen Pakete werden installiert:
   systemd
[…]
Die folgenden NEUEN Pakete werden installiert:
  systemd
[…]

Habe mir nicht alle Beiträge im Detail durchgelesen, aber: Mal mit --no-install-recommends probiert?

Code: Alles auswählen

# apt install --no-install-recommends pavucontrol

Empfohlene Pakete ziehen gern mal unerwartete, zusätzliche Sachen mit sich.

[guennid]

Automatische Installation empfohlener Pakete wird bei mir in /etc/apt/apt.conf nach der Installation des Grundsystems grundsätzlich abgeschaltet.

Grüße Günther

[smutbert]

Bist du 100%ig sicher?
pulseaudio hat nämlich dbus-user-session (das von systemd abhängt) in den recommends drin. Was sagt auf dem 32-Bit System

Code: Alles auswählen

apt-get -s install --no-install-recommends pavucontrol

[guennid]

Hundert pro. Ich habe nachgeguckt. apt.conf ist da und der Eintrag steht drin.

Code: Alles auswählen

apt-get -s install --no-install-recommends pavucontrol

wirft ebenfalls sysvinit-core raus.

Grüße, Günther

[smutbert]

aber wirft es auch dbus-user-session aus? (Das habe ich noch immer zumindest als indirekte Ursache in Verdacht.)

[guennid]

Die ist doch auf dem 32er gar nicht installiert.

[guennid]

Könnte es am fehlenden consolekit liegen? Ich erinnerte gerade, dass ich ein ähnliches Problem unter stetch mit xfburn hatte. (1) Auf dem 64er System ist consolekit nach wie vor installiert. Das wird hier nicht so einfach zu installieren sein, wie damals bei xfburn.
(1) viewtopic.php?f=29&t=171742&hilit=xfburn

[smutbert]

Aber es möchte gemeinsam mit dbus installiert werden und beide ziehen zwangsweise systemd mit.

Mit ist momentan eher unklar wie du auf dem 64Bit-System ohne diese Pakete zu pavucontrol bzw. pulseaudio gekommen bist. Hast du vielleicht auf dem 64Bit-System mehr oder andere selbst gebaute Dummy-Pakete installiert?

Darauf dass das mit consolekit zu tun haben könnte, sehe ich bis jetzt keinen Hinweis.

[guennid]

Hast du vielleicht auf dem 64Bit-System mehr oder andere selbst gebaute Dummy-Pakete installiert?

Es läuft ein via equis erstellter udev-dummy.

[smutbert]

Aber den hast du ja auf beiden System gleichermaßen. Eine andere Spur ist libcanberra-gtk3-0, weil das in einer langen Kette von Abhängigkeiten zur Installation von systemd führt:

libcanberra-gtk3-0 → libgtk-3-0 → libsoup2.4-1 → glib-networking → gsettings-desktop-schemas → dconf-gsettings-backend | gsettings-backend (=dconf-gsettings-backend) → dconf-service → default-dbus-session-bus | dbus-session-bus (=dbus-user-session) → libpam-systemd, systemd

pavucontrol selbst ist das Paket, das von libcanberra-gtk3-0 (und auch libgtk-3-0) abhängt. Nachdem die Abhängigeiten unter amd64 dieselben sind, frage ich mich wie du pavucontrol dort ohne diese Pakete installieren konntest.
Sind beide Systeme auf dem aktuellen Stand von buster?
Im Zweifelsfall fangen wir am Anfang der Abhängigkeitskette an und schauen uns die auf dem amd64-System installierten Versionen an:

Code: Alles auswählen

$ dpkg -l | grep -e 'gtk3' -e 'gtk-3' -e 'pavu'

(Die einzige mögliche Erklärung, die mir momentan einfällt, ist, dass unter amd64 vielleicht eine ältere Versionen mit noch anderen Abhängigkeiten installiert ist.)