[Gelöst] apt-upgrade schlägt fehl (systemd)

[Fischtag]

Hallo,

ich habe ein Problem mit Updates und komme nicht mehr weiter...

Code: Alles auswählen

# apt update && apt upgrade
Holen:1 http://security.debian.org/debian-security bullseye-security InRelease [48,4 kB]
OK:2 http://deb.debian.org/debian bullseye InRelease
Holen:3 http://deb.debian.org/debian bullseye-updates InRelease [44,1 kB]
Es wurden 92,4 kB in 0 s geholt (212 kB/s).
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Aktualisierung für 20 Pakete verfügbar. Führen Sie »apt list --upgradable« aus, um sie anzuzeigen.
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Paketaktualisierung (Upgrade) wird berechnet… Fertig
Die folgenden NEUEN Pakete werden installiert:
  linux-image-5.10.0-18-amd64
Die folgenden Pakete werden aktualisiert (Upgrade):
  base-files curl grub-common grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed grub2-common krb5-locales libc-bin libc-l10n libcurl3-gnutls libcurl4 libgdk-pixbuf-2.0-0
  libgdk-pixbuf2.0-common libk5crypto3 linux-image-amd64 locales mokutil publicsuffix systemd-sysv
20 aktualisiert, 1 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
4 nicht vollständig installiert oder entfernt.
Es müssen noch 0 B von 67,8 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 318 MB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] 
Changelogs werden gelesen... Fertig
Vorkonfiguration der Pakete ...
systemd (247.3-7+deb11u1) wird eingerichtet ...
Die Gruppe »systemd-journal« existiert bereits und ist keine Systemgruppe. Programmende.
dpkg: Fehler beim Bearbeiten des Paketes systemd (--configure):
 »installiertes systemd-Skript des Paketes post-installation«-Unterprozess gab den Fehlerwert 1 zurück
Fehler traten auf beim Bearbeiten von:
 systemd
E: Sub-process /usr/bin/dpkg returned an error code (1)

Ein Versuch es weiter selbst aufzulösen:

Code: Alles auswählen

# apt install -f
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 20 nicht aktualisiert.
4 nicht vollständig installiert oder entfernt.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
systemd (247.3-7+deb11u1) wird eingerichtet ...
Die Gruppe »systemd-journal« existiert bereits und ist keine Systemgruppe. Programmende.
dpkg: Fehler beim Bearbeiten des Paketes systemd (--configure):
 »installiertes systemd-Skript des Paketes post-installation«-Unterprozess gab den Fehlerwert 1 zurück
udev (247.3-7+deb11u1) wird eingerichtet ...
Die Gruppe »input« existiert bereits und ist keine Systemgruppe. Programmende.
dpkg: Fehler beim Bearbeiten des Paketes udev (--configure):
 »installiertes udev-Skript des Paketes post-installation«-Unterprozess gab den Fehlerwert 1 zurück
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von libpam-systemd:amd64:
 libpam-systemd:amd64 hängt ab von systemd (= 247.3-7+deb11u1); aber:
  Paket systemd ist noch nicht konfiguriert.

dpkg: Fehler beim Bearbeiten des Paketes libpam-systemd:amd64 (--configure):
 Abhängigkeitsprobleme - verbleibt unkonfiguriert
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von libnss-systemd:amd64:
 libnss-systemd:amd64 hängt ab von systemd (= 247.3-7+deb11u1); aber:
  Paket systemd ist noch nicht konfiguriert.

dpkg: Fehler beim Bearbeiten des Paketes libnss-systemd:amd64 (--configure):
 Abhängigkeitsprobleme - verbleibt unkonfiguriert
Trigger für initramfs-tools (0.140) werden verarbeitet ...
update-initramfs: Generating /boot/initrd.img-5.10.0-17-amd64
Fehler traten auf beim Bearbeiten von:
 systemd
 udev
 libpam-systemd:amd64
 libnss-systemd:amd64

Leider hilft das nicht.
Ich habe auch versucht, ob

Code: Alles auswählen

dpkg -r --force-depends libnss-systemd

(siehe https://www.debian.org/releases/stable/ ... ml#trouble etwas bewirkt, ebenfalls nicht.
Reboot und erneutes upgrade /install -f hilft auch nicht.
Systemd zu entfernen finde ich beängstigend ... ich hoffe jemand hat eine Idee?

[cosinus]

Du könntest ein reinstall probieren:

Code: Alles auswählen

apt install systemd --reinstall -s

das -s für Simulation. Kannst ja mal schauen was da passiert.

[DeletedUserReAsG]

Die relevante Information ist:

Code: Alles auswählen

Die Gruppe »systemd-journal« existiert bereits und ist keine Systemgruppe. Programmende.

Das wäre zu beheben; außerdem würde mich, wenn es meine Kiste wäre, dringend interessieren, was das verursacht hat.

[JTH]

Das wäre zu beheben; außerdem würde mich, wenn es meine Kiste wäre, dringend interessieren, was das verursacht hat.

Betrifft auch noch ne zweite Gruppe:

Code: Alles auswählen

Die Gruppe »input« existiert bereits und ist keine Systemgruppe. Programmende.

Schon sehr merkwürdig bis verdächtig, wer oder was da am Werk war.

[Fischtag]

Du könntest ein reinstall probieren:

Code: Alles auswählen

apt install systemd --reinstall -s

das -s für Simulation. Kannst ja mal schauen was da passiert.

Sieht unverdächtig aus ...

Code: Alles auswählen

# apt install systemd --reinstall -s
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
0 aktualisiert, 0 neu installiert, 1 erneut installiert, 0 zu entfernen und 18 nicht aktualisiert.
4 nicht vollständig installiert oder entfernt.
Inst systemd [247.3-7+deb11u1] (247.3-7+deb11u1 Debian:11.5/stable [amd64])
Conf systemd (247.3-7+deb11u1 Debian:11.5/stable [amd64])
Conf udev (247.3-7+deb11u1 Debian:11.5/stable [amd64])
Conf libpam-systemd (247.3-7+deb11u1 Debian:11.5/stable [amd64])
Conf libnss-systemd (247.3-7+deb11u1 Debian:11.5/stable [amd64])

[Fischtag]

... aber nur bis man es ausführt ...

Code: Alles auswählen

# apt install systemd --reinstall
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
0 aktualisiert, 0 neu installiert, 1 erneut installiert, 0 zu entfernen und 18 nicht aktualisiert.
4 nicht vollständig installiert oder entfernt.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
E: Internal Error, No file name for systemd:amd64

[JTH]

Sieht unverdächtig aus ...

Code: Alles auswählen

# apt install systemd --reinstall -s
[…]

Die Ausgabe wird dir hier nicht weiterhelfen. Ein apt install --simulate simuliert nicht die tatsächliche Ausführung der Maintainerskripte (postinst etc.), in denen bei dir hier das Problem entsteht:

Code: Alles auswählen

dpkg: Fehler beim Bearbeiten des Paketes systemd (--configure):
 »installiertes systemd-Skript des Paketes post-installation«-Unterprozess gab den Fehlerwert 1 zurück
[…]
dpkg: Fehler beim Bearbeiten des Paketes udev (--configure):
 »installiertes udev-Skript des Paketes post-installation«-Unterprozess gab den Fehlerwert 1 zurück

[JTH]

Das wäre zu beheben; außerdem würde mich, wenn es meine Kiste wäre, dringend interessieren, was das verursacht hat.

Um niemands Beobachtung mal auf den Grund zu gehen: Wie sehen denn auf dem Rechner die Gruppen-IDs der Systemgruppen aus?

Code: Alles auswählen

awk -F: '$3 < 1000' /etc/group

Falls du die enthaltenen Benutzernamen lieber verstecken möchtest:

Code: Alles auswählen

awk -F: '$3 < 1000 { print $1,$3 }' /etc/group

[KP97]

4 nicht vollständig installiert oder entfernt

Solange das erscheint, kommst Du nicht weiter.
Du kannst mal versuchen, in /var/lib/dpkg/info/ in den Scripten systemd.postinst und udev.postinst (die mit dem Fehlerwert 1)
in die zweite Zeile ein exit 0 einzutragen, dann apt install -f und anschließend systemd reinstallieren.

[Fischtag]

Zu den "fehlenden" Systemgruppen - /etc/passwd und /etc/group haben nachvollziehbare Zeitstempel, auch lastlog, netstat und iftop zeigen nichts auffälliges oder unerwartetes, um mal ein Angriffsszenario weiter auszugrenzen.

Code: Alles auswählen

# grep systemd-journal /etc/group
systemd-journal:x:101:

Code: Alles auswählen

 grep input /etc/group
input:x:104:

... existieren.

Code: Alles auswählen

# awk -F: '$3 < 1000 { print $1,$3 }' /etc/group
root 0
daemon 1
bin 2
sys 3
adm 4
tty 5
disk 6
lp 7
mail 8
news 9
uucp 10
man 12
proxy 13
kmem 15
dialout 20
fax 21
voice 22
cdrom 24
floppy 25
tape 26
sudo 27
audio 29
dip 30
www-data 33
backup 34
operator 37
list 38
irc 39
src 40
gnats 41
shadow 42
utmp 43
video 44
sasl 45
plugdev 46
staff 50
games 60
users 100
systemd-journal 101
systemd-network 102
systemd-resolve 103
input 104
kvm 105
render 106
crontab 107
netdev 108
messagebus 109
systemd-timesync 110
ssh 111
systemd-coredump 999
ntp 112
Debian-exim 113
cmk-agent 998

Die Umsichtigkeit mit der Ihr Befehle vorschlagt finde ich gut!
Und ebenfalls vielen Dank für die schnelle Hilfe soweit!

[Fischtag]

4 nicht vollständig installiert oder entfernt

Solange das erscheint, kommst Du nicht weiter.
Du kannst mal versuchen, in /var/lib/dpkg/info/ in den Scripten systemd.postinst und udev.postinst (die mit dem Fehlerwert 1)
in die zweite Zeile ein exit 0 einzutragen, dann apt install -f und anschließend systemd reinstallieren.

Vielen Dank, das hat geholfen!

[KP97]

Gern geschehen...
vielleicht sehen wir Dich jetzt ja mal öfter, 11 Beiträge seit 2003 ist ja nicht so dolle...;-)

[JTH]

vielleicht sehen wir Dich jetzt ja mal öfter, 11 Beiträge seit 2003 ist ja nicht so dolle...

Debian funktioniert halt so problemlos

Vielen Dank, das hat geholfen!

Das, was du jetzt gemacht hast, unterdrückt ja eigentlich nur den Fehler. Die denkbare Ursache (verbogene Gruppendefinitionen-/vorgaben) könnte immer noch existieren und später wieder Probleme bereiten. Der Aufruf von

Code: Alles auswählen

addgroup --system systemd-journal

in der systemd.postinst ist nämlich nicht neu. Eigentlich sollte dort beim Upgrade ein weniger dramatisches und trotzdem erfolgreiches

Code: Alles auswählen

addgroup: The group `systemd-journal` already exists as a system group. Exiting.

herauskommen.

Sind bei dir evtl. die Grenzen für die Gruppen-IDs anders festgelegt?

Code: Alles auswählen

grep -E 'FIRST_|LAST_' /etc/adduser.conf

[DeletedUserReAsG]

Das, was du jetzt gemacht hast, unterdrückt ja eigentlich nur den Fehler.

Eigentlich ist es noch schlimmer: es sorgt dafür, dass die Pakete nicht sauber installiert werden – was einem unter Umständen früher oder später böse auf die Füße fallen kann.

[Fischtag]

Ahh, ich dachte das ist nur ein temporärer Eintrag, der nach dem Update rausfliegt. Dauerhaft will ich das exit 0 nicht haben ... mal schauen wie es sich danach verhält.

In /etc/adduser.conf hatte ich nichts verändert:

Code: Alles auswählen

# grep -E 'FIRST_|LAST_' /etc/adduser.conf
# FIRST_SYSTEM_[GU]ID to LAST_SYSTEM_[GU]ID inclusive is the range for UIDs
FIRST_SYSTEM_UID=10000
LAST_SYSTEM_UID=99999
FIRST_SYSTEM_GID=10000
LAST_SYSTEM_GID=99999
# FIRST_[GU]ID to LAST_[GU]ID inclusive is the range of UIDs of dynamically
FIRST_UID=1000
LAST_UID=59999
FIRST_GID=1000
LAST_GID=59999

Mir ist schleierhaft, woher das kommt, vermutlich mit dem Update auf 11.5 ...

[KP97]

Ahh, ich dachte das ist nur ein temporärer Eintrag, der nach dem Update rausfliegt.

Das ist auch nur temporär, nach dem reinstall wird das Script wieder mit den originalen Einträgen überschrieben, keine Sorge.

Diese Methode kann man anwenden, wenn es im Paketmanager mal klemmt, so wie bei Dir jetzt, ohne das der Fehler nachzuvollziehen ist.
Außerdem deutet der Fehlerwert 1 darauf hin, daß die Installation schon vorher beendet wird, ohne das Script ganz auszuführen.
Dabei kann überhaupt nichts passieren, Du erstellst es ja neu.

[KP97]

...es sorgt dafür, dass die Pakete nicht sauber installiert werden – was einem unter Umständen früher oder später böse auf die Füße fallen kann.

Nein, tut es nicht. Es wird ein reinstall ausgeführt, wobei alle Scripte bzw. Pakete wieder neu erstellt werden.

[DeletedUserReAsG]

Es wird ein reinstall ausgeführt, wobei alle Scripte bzw. Pakete wieder neu erstellt werden.

Wenn diese Pakete also vollständig samt Postinstall-Scripten installiert worden wären, hätte dann der Fehler nicht genauso wieder auftreten müssen?

[KP97]

Der TE sagt, daß nach Ausführen dieser Aktion alles wieder ok ist. Und so kenne ich das auch, ich habe auch schon in der Vergangenheit diese Methode angewandt, ohne das es jemals danach einen Fehler gegeben hätte. Manchmal ist es ja so, es hakt an einer Ecke und man will nicht das ganze System umgraben, um stundenlang etwas zu suchen,
was doch nicht sichtbar ist.
Zugegeben, das ist die Holzhammermethode, hilft aber meistens.

[DeletedUserReAsG]

Der TE sagt, daß nach Ausführen dieser Aktion alles wieder ok ist.

Dann warten wir mal bis zum nächsten Update besagter Pakete.

[JTH]

Wenn diese Pakete also vollständig samt Postinstall-Scripten installiert worden wären, hätte dann der Fehler nicht genauso wieder auftreten müssen?

Guter Punkt, so auf den ersten Blick hätte das eigentlich nicht klappen dürfen. Vor dem postinst wird ein Paket stumpf entpackt und das hätte jede Änderung dort überschreiben müssen.

Ich könnt mir nur vorstellen, ohne in den Code von apt und dpkg zu spicken, dass das Paket hier ja im Zustand „entpackt, aber nicht konfiguriert“ gewesen ist und deshalb das erneute Entpacken, da Version identisch, übersprungen wurde.

Wenn ich als Gegenprobe bei einem gerade sauber installierten Paket ein exit 42 im bestehenden postinst platziere, läuft ein anschließendes reinstall nämlich trotzdem ohne Fehler durch. Weil das bestehende postinst beim reinstall eben erstmal überschrieben wird.

Manchmal ist es ja so, es hakt an einer Ecke und man will nicht das ganze System umgraben, um stundenlang etwas zu suchen, was doch nicht sichtbar ist.

Oh, hier ist was sichtbar:

In /etc/adduser.conf hatte ich nichts verändert:

Code: Alles auswählen

# grep -E 'FIRST_|LAST_' /etc/adduser.conf
# FIRST_SYSTEM_[GU]ID to LAST_SYSTEM_[GU]ID inclusive is the range for UIDs
FIRST_SYSTEM_UID=10000
LAST_SYSTEM_UID=99999
FIRST_SYSTEM_GID=10000
LAST_SYSTEM_GID=99999
# FIRST_[GU]ID to LAST_[GU]ID inclusive is the range of UIDs of dynamically
FIRST_UID=1000
LAST_UID=59999
FIRST_GID=1000
LAST_GID=59999

Das ist einigermaßen verkorkst ungewöhnlich. Irgendetwas oder jemand hat da definitiv was modifiziert: Die Bereiche für System- und dynamische Benutzer und -Gruppen überschneiden sich. Außerdem liegen die ganzen Systemgruppen, die du oben mit dem awk-Aufruf gezeigt hast, alle nicht in dem festgelegten Bereich für Systemgruppen. Deshalb hat sich addgroup im systemd-postinst auch beschwert und das Upgrade ist gescheitert. Und so wird es bei jedem Upgrade anderer Pakete, die Systemgruppen benutzen, in Zukunft weitergehen.

So sieht es standardmäßig in einer Debian-Installation aus:

Code: Alles auswählen

~$ grep -E 'FIRST_|LAST_' /etc/adduser.conf 
# FIRST_SYSTEM_[GU]ID to LAST_SYSTEM_[GU]ID inclusive is the range for UIDs
FIRST_SYSTEM_UID=100
LAST_SYSTEM_UID=999
FIRST_SYSTEM_GID=100
LAST_SYSTEM_GID=999
# FIRST_[GU]ID to LAST_[GU]ID inclusive is the range of UIDs of dynamically
FIRST_UID=1000
LAST_UID=59999
FIRST_GID=1000
LAST_GID=59999

Natürlich darf man die Bereiche verändern, dafür ist die Konfiguration ja da. Aber die bestehenden Gruppen- und User-IDs sollten wohl weiter in den veränderten Bereichen liegen.


Was is’n das für ein System? Ein Desktop, was virtuelles, ein Server? Ein einzelner Benutzer oder mehrere – die alle Zugriff auf den root-Benutzer haben? Über mehrere Debian-Releases durch Upgrades mitgegangen?

[Fischtag]

So sieht es standardmäßig in einer Debian-Installation aus:

Code: Alles auswählen

~$ grep -E 'FIRST_|LAST_' /etc/adduser.conf 
# FIRST_SYSTEM_[GU]ID to LAST_SYSTEM_[GU]ID inclusive is the range for UIDs
FIRST_SYSTEM_UID=100
LAST_SYSTEM_UID=999
FIRST_SYSTEM_GID=100
LAST_SYSTEM_GID=999
# FIRST_[GU]ID to LAST_[GU]ID inclusive is the range of UIDs of dynamically
FIRST_UID=1000
LAST_UID=59999
FIRST_GID=1000
LAST_GID=59999

Uuups, Du hast vollkommen recht, das habe ich jetzt angepasst, da hat es wohl jemand anders zu gut gemeint. Das dürfte dann ja auch die Ursache des Problems sein.
Tatsächlich hat der mysql-Nutzer jetzt eine UID > 10000

Code: Alles auswählen

mysql:x:10001:10002:MySQL Server,,,:/nonexistent:/bin/false

Sollte ich die UID ändern - eigentlich sollte das nichts ausmachen, oder?