Bei einem update-Versuch wo sehr viele Pakete und auch der kernel von 6.6.3-arch1-1 auf linux-6.7.arch3-1 aktualisiert werden sollten kam es nach etwa 2/3 zum total freeze am Tuxedo Laptop. Kein image found.
Nachdem ich über arch-chroot den kernel neu gebildet hatte kommen jede Menge eigenartige FM:

bei booten kommt:

/dev/mapper/luks-576072ce-cefd-402a-a31b-b7aedf9eff35: clean, 2660337/59867136 files, 201274726/239411664 blocks
[FAILED] Failed to start D-Bus System Message Bus.
[DEPEND] Dependency failed for Network Manager.
[DEPEND] Dependency failed for Network Manager Wait Online.
[FAILED] Failed to start D-Bus System Message Bus.
[FAILED] Failed to start D-Bus System Message Bus.
[FAILED] Failed to start D-Bus System Message Bus.
[FAILED] Failed to start D-Bus System Message Bus.
[FAILED] Failed to start D-Bus System Message Bus.
[FAILED] Failed to start Bluetooth service.
[FAILED] Failed to start User Login Management.
[FAILED] Failed to start Avahi mDNS/DNS-SD Stack.
[FAILED] Failed to start D-Bus System Message Bus.
[FAILED] Failed to start User Login Management.
[FAILED] Failed to start D-Bus System Message Bus.
[FAILED] Failed to start Light Display Manager.

dmesg endet mit:
[ 1540.298053] audit: tuype=1130 audit(1705867212.253:544): pid=1 uid=0 auid=4294967295 ses=4294967295 msg="unit=reflector comm="systemd" exe="/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=failed’

Ich hab im chroot bereits systemd und auch dbus reinstalliert - aber ohne Erfolg.

Was kann ich noch tun ?

  • brikler hat auf diesen Beitrag geantwortet.

    Was meinst du mit "Kernel neu gebildet"? mkinitcpio -p linux?

    rob-arch Was kann ich noch tun ?

    ich würde mit systemd-nspawn chrooten, und dann nach den servce status schauen:systemctl status dbus

    Ich habe genau das selbe Problem gehabt, aber keinen Freeze beim Update.
    Ich habe das System im Runmode 3 gestartet, dort aber auch keinen netzwerkzugriff, weil Dbus-Dienst nicht gestartet wurde.

    Mir ist dann aufgefallen (beim Vergleich der Installation mit einer Notebook-Installation), dass im Verzeichnis /usr/lib/systemd/system ganz einfach die Datei "dbus.service" entfernt worden war.

    Ich habe eine neue Datei erstellt mit folgendem Inhalt, und dann lief wieder alles. Ihc musste lediglich meinen Display-Manager zu gdm wechseln,d a der von Plasma nicht mehr lief. Vermutlich hat das Update der Plasma-Installation auch zu diesem Fehler geführt.

    [Unit]
    Description=D-Bus System Message Bus
    Documentation=man:dbus-daemon
    Requires=dbus.socket

    [Service]
    Type=notify
    NotifyAccess=main
    ExecStart=/usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
    ExecReload=/usr/bin/dbus-send --print-reply --system --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig
    OOMScoreAdjust=-900

    • Martin-MS hat auf diesen Beitrag geantwortet.

      Minihawk Mir ist dann aufgefallen (beim Vergleich der Installation mit einer Notebook-Installation), dass im Verzeichnis /usr/lib/systemd/system ganz einfach die Datei "dbus.service" entfernt worden war.

      Es gab kürzliche eine Änderung, und zwar wurde der dbus-broker Standard anstatt des D-Bus daemon. Beim Update wurde ich seinerzeit gefragt, ob ich für die dbus-units das Paket dbus-broker-units oder dbus-daemon-units installieren wolle; ich habe mich dann erst mal für die zweite Variante und damit der weiteren Nutzung des D-Bus daemon entschieden, weil ich das auf produktiven Systemen für sicherer hielt.

      Die Datei dbus.service gibt es aber in beiden Paketen. Vielleicht gibt das pacman-Log darüber Auskunft, was passiert sein könnte. Ich würde jedenfalls nicht eine eigene dbus.service erstellen sondern das entsprechende Paket neu installieren, da die Dateien in den Paketen unterschiedliche Inhalte haben und zur Installation passen müssen.

      Interessant wäre vielleicht noch zu wissen, welches der beiden Pakete installiert wurde und ob es möglicherweise Probleme mit der Installation der dbus-broker-units gibt.

      • Minihawk hat auf diesen Beitrag geantwortet.

        Martin-MS Was anderes blieb mir ja gar nicht übrig, als die Datei von Hand anzupassen.
        Das System war nicht in der Lage, etwas zu installieren, weil keinerlei Netzwerk-Verbindung ohne dbus laufen wollte. Ich schau jetzt mal nach dbus-broker oder dbus-daemon...

        Edith meint: Hab ich nicht herausfinden können. Ich habe aber etwas anderes versucht. Ich habe auf dem selben Rechner eine weitere SSD eingebaut, auf der ein (weniger ausgebautes) Archlinux liegt. Dieses Archlinux war schon länger nicht mehr upgedatet worden,d eshalb musste ich erst einmal die ganzen Schlüssel neu aufbauen.
        Und was soll ich sagen, nach dem dann folgenden Update ist auch Dbus im Ors...
        Natürlich ist das genau die selbe Hardware (Mainboard/CPU/Graphik) wie im ersten Fall. Aber es scheint hier schon etwas im Busch zu sein...

        • Martin-MS hat auf diesen Beitrag geantwortet.

          Minihawk Was anderes blieb mir ja gar nicht übrig, als die Datei von Hand anzupassen.
          Das System war nicht in der Lage, etwas zu installieren, weil keinerlei Netzwerk-Verbindung ohne dbus laufen wollte.

          Wenn sich das Installationspaket noch im pacman-Cache befindet, kann man es von dort auch ohne Netzwerkverbindung neu installieren. Ansonsten vom Installationsmedium booten, dann hat man wieder eine Netzwerkverbindung. Danach die root-Partition einhängen, mit arch-chrootin die Installation wechseln und dort dann das Paket neu installieren und evtl. weitere Reparaturmaßnahmen durchführen.

          Minihawk Und was soll ich sagen, nach dem dann folgenden Update ist auch Dbus im Ors...

          Fehlte wieder die dbus.service? Welches Paket hast du installiert, dbus-broker-units oder dbus-daemon-units? Hast du es mal mit dem jeweils anderen Paket versucht?

          Minihawk Aber es scheint hier schon etwas im Busch zu sein...

          Das ist denkbar, im englischsprachigen Forum habe ich auch schon aktuelle Beiträge gesehen, die DBus-Probleme nach einem Update zum Inhalt hatten. Es scheint aber nur unter bestimmten Bedingungen aufzutreten, sonst wären die Meldungen zahlreicher. Ich hatte gestern mal testweise eine VM aktualisiert und bewusst zu dbus-broker-units gewechselt, das lief aber problemlos und danach startete das System auch wieder.

          4 Tage später

          Ich habe mir das heute noch einmal im Rahmen des Updates eines Notebooks angesehen, bei dem ich auch wieder bewusst den dbus-broker installiert habe, und alles ist gut gelaufen.

          Es ist tatsächlich so, dass das Paket dbus-broker-units nichts anderes als einen Link dbus.service nach dbus-broker.service mitbringt. Bei der Installation von dbus-broker-units wird das Pakets dbus-broker als Abhängigkeit nachgezogen, umgekehrt aber nicht. Wer also aus welchem Grund auch immer nur dbus-broker installiert, dem wird die Datei dbus-servicefehlen und damit auch der Link nach dbus-broker.service, folglich wird D-Bus nicht mehr gestartet und es kommt zu den beschriebenen Problemen.

          Beim dbus-daemon sieht es etwas anders aus; bis zur Version 1.14.10-1 befand sich dbus.service noch als Datei im Paket dbus, wurde mit dem rebuild 1.14.10-2 entfernt und in das neue Paket dbus-daemon-units verschoben. Das Paket dbus-daemon-units hat zwar eine Abhängigkeit auf dbus, aber umgekehrt wieder nicht. Wer also nur dbus installiert, wird also wieder ohne eine dbus.service dastehen.

          systemd hat eine Abhängigkeit auf dbus-units bekommen, das von dbus-daemon-unitsund dbus-broker-units bereitgestellt wird, die miteinander im Konflikt stehen. Bei einer Aktualisierung von systemd wird man gefragt, welches der beiden Pakete installiert werden soll. Falls nur eine Teilaktualisierung ohne systemd aber mit dbus vorgenommen wird, könnte die Situation entstehen, dass ein dbus ohne die benötigten Services installiert wird.

          Denkbar wäre auch, dass durch Abstimmungs- oder Mirrorprobleme die dbus-Pakete vor dem systemd-Paket ausgeliefert wurden, was dann ebenfalls zu den fehlenden Services führen würde. Daran glaube ich schon eher, da das Problem nur einige Benutzer in einem relativ kleinen Zeitfenster betraf.

          Eine Gesamtsystemaktualisierung sollte das Problem eigentlich beheben.