Guten Morgen ...
ich habe eben ein ...
doas apt update && doas apt --solver 3.0 full-upgrade
... durchgeführt und es lief - mit einer Fehlermeldung für eine unerfüllte Abhängigkeit - durch.
Nach einem Neustart war der Fenstermanager offensichtlich defekt, d.h. die Titelzeile und der Fensterrahmen erschien nicht mehr und die Fenster ließen sich auf graphischem Weg nicht mehr schließen und die Textausgaben in der Konsole liefen nach unten ins "Nirvana" und liessen sich nicht mehr zurück scrollen. Auch schien sich der Bildschirm selbst erweitert zu haben: am rechten Rand erschien eine Laufleiste, einige Icons waren unter dem unteren Bildschirmrand verschwunden.
Ebenso war die Menüleiste am unteren Bildrand verschwunden.
Daraufhin führte ich ein erneutes ...
doas apt update && doas apt --solver 3.0 full-upgrade
... durch und erhielt das:
[05:55:27][isegrimm@T-A-K-A-Y-A:~]$ dofu
OK:1 https://deb.debian.org/debian unstable InRelease
OK:2 https://dl.winehq.org/wine-builds/debian trixie InRelease
OK:3 https://ftp.gwdg.de/pub/linux/siduction/extra unstable InRelease
OK:4 https://packages.siduction.org/fixes unstable InRelease
Aktualisierung für 1 Paket verfügbar. Führen Sie »apt list --upgradable« aus, um es anzuzeigen.
Probieren Sie »apt --fix-broken install«, um dies zu korrigieren.
Unsatisfied dependencies:
libosmesa6 : Hängt ab von: libllvm19 (>= 1:19.1.0) ist aber nicht installiert
mesa-libgallium : Hängt ab von: libllvm19 (>= 1:19.1.0) ist aber nicht installiert
mesa-vulkan-drivers : Hängt ab von: libllvm19 (>= 1:19.1.0) ist aber nicht installiert
Error: Unerfüllte Abhängigkeiten. Versuchen Sie »apt --fix-broken install« ohne Angabe eines Pakets (oder geben Sie eine Lösung an).
Also befolgte ich den Rat und führte ein ...
doas apt --fix-broken install
... durch.
Das Ergebnis ...
Abhängigkeiten werden korrigiert ... Fertig
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr benötigt:
libavdevice60 libgeos3.12.2 libkwalletbackend5-5 libllvm18 libllvm18:i386 libmodule-pluggable-perl libpoppler-cpp0t64 libpoppler134 libpoppler134:i386 linux-headers-6.10.9-1-siduction-amd64 linux-image-6.10.9-1-siduction-amd64
Verwenden Sie »apt autoremove«, um sie zu entfernen.
Installing dependencies:
libllvm19
Summary:
Upgrading: 0, Installing: 1, Removing: 0, Not Upgrading: 1
86 nicht vollständig installiert oder entfernt.
Download size: 0 B / 26,0 MB
Space needed: 130 MB / 199 GB available
Continue? [J/n]
(Lese Datenbank ... 640778 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../libllvm19_1%3a19.1.0-3_amd64.deb ...
Entpacken von libllvm19:amd64 (1:19.1.0-3) ...
dpkg: Fehler beim Bearbeiten des Archivs /var/cache/apt/archives/libllvm19_1%3a19.1.0-3_amd64.deb (--unpack):
Versuch, gemeinsam benutztes »/usr/lib/llvm-19/lib/libLLVM.so.19.1« zu überschreiben, welches verschieden von anderen Instanzen des Paketes libllvm19:amd64 ist
Fehler traten auf beim Bearbeiten von:
/var/cache/apt/archives/libllvm19_1%3a19.1.0-3_amd64.deb
Error: Sub-process /usr/bin/dpkg returned an error code (1)
... war eher unbefriedigend.
Genutzter Desktop: KDE
Hat jemand eine Idee?
Guten Morgen,
sieht bei mir ähnlich aus:
Fehler traten auf beim Bearbeiten von:
/var/cache/apt/archives/libllvm19_1%3a19.1.0-3_i386.debich verwende XFCE
Continue? [J/n]
libgcc-s1:amd64 (14.2.0-5) wird eingerichtet ...
libgpg-error0:amd64 (1.50-4) wird eingerichtet ...
(Lese Datenbank ... 590023 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../libllvm19_1%3a19.1.0-3_i386.deb ...
Entpacken von libllvm19:i386 (1:19.1.0-3) ...
dpkg: Fehler beim Bearbeiten des Archivs /var/cache/apt/archives/libllvm19_1%3a19.1.0-3_i386.deb (--unpack):
Versuch, gemeinsam benutztes »/usr/lib/llvm-19/lib/libLLVM.so.19.1« zu überschreiben, welches verschieden von anderen Instanzen des Paketes libllvm19:i386 ist
Fehler traten auf beim Bearbeiten von:
/var/cache/apt/archives/libllvm19_1%3a19.1.0-3_i386.deb
needrestart is being skipped since dpkg has failed
Quotedpkg -l | grep libllvm
ii libllvm16t64:amd64 1:16.0.6-27+b1 amd64 Modular compiler and toolchain technologies, runtime library
ii libllvm17t64:amd64 1:17.0.6-18 amd64 Modular compiler and toolchain technologies, runtime library
ii libllvm18:amd64 1:18.1.8-11 amd64 Modular compiler and toolchain technologies, runtime library
ii libllvm18:i386 1:18.1.8-11 i386 Modular compiler and toolchain technologies, runtime library
iU libllvm19:amd64 1:19.1.0-3 amd64 Modular compiler and toolchain technologies, runtime library
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082495
edlin
Danke ...
Na dann warten wir mal ab :)
xfce + labwc
den solver verwende ich weiterhin nur in Ausnahmefällen
doas apt dist-upgrade
Das folgende Paket wurde automatisch installiert und wird nicht mehr benötigt:
libllvm18
Verwenden Sie »apt autoremove«, um es zu entfernen.
Upgrading:
bind9-dnsutils bind9-libs libegl-mesa0 libgl1-mesa-dri libglx-mesa0 libnfsidmap1 mesa-libgallium mesa-vdpau-drivers nfs-common
bind9-host dnsutils libgbm1 libglapi-mesa libjson-c5 manpages-de mesa-va-drivers mesa-vulkan-drivers python3-inflect
Installing dependencies:
libllvm19
Summary:
Upgrading: 18, Installing: 1, Removing: 0, Not Upgrading: 0
Download size: 55,9 MB
Space needed: 92,0 MB / 34,6 GB available
Continue? [J/n]
dpkg -l | grep libllvm
ii libllvm19:amd64 1:19.1.0-3 amd64 Modular compiler and toolchain technologies, runtime library
386'er Pakete gibt es hier nicht.
Hier KDE ohne 386er Pakete: (Daher?) Keine Probleme.
Wer's ("mit 386") ausprobieren will, sollte das libllvm19:386 (gegebenenfalls inklusive der "Abhängigkeiten") löschen (, aber nicht "purgen"), wenn er kann und es nach einer Paketkorrektur wieder aufspielen.
Die Debian QA scheint auch nicht mehr das Wahre zu sein. Das gleiche Problem gabs bei llvm-18, da hatte ich es gemeldet, bevor Debian llvm-18 für mesa benutzt hat, es hat aber ewig gedauert, bis llvm-18 gefixt wurde. Nun geht mit llvm-19 das gleiche Spiel wieder los, nur diesmal ist die Kacke schon am dampfen und macht alle Systeme mit Multiarch kaputt.
Quote from: ro_sid on 2024/09/21, 11:43:53
...
Wer's ("mit 386") ausprobieren will, sollte das libllvm19:386 (gegebenenfalls inklusive der "Abhängigkeiten") löschen (, aber nicht "purgen"), wenn er kann und es nach einer Paketkorrektur wieder aufspielen.
das ist bei mir ein Rattenschwanz von 14 abhänigen Paketen (wg. nvivia:i386), klappt aber.
... und vorsicht, kleiner patzer, es muß libllvm19:i386 heißen ... und man sollte mit libllvm18:i386 beginnen.
Danke für den Tip!
apt remove libllvm18:i386 libllvm19:i386 libosmesa6:i386 mesa-libgallium:i386 mesa-vulkan-drivers:i386 libglx-mesa0:i386 libgbm1:i386 libegl-mesa0:i386 libegl1:i386 libgl1-mesa-dri:i386 libgl1-mesa-glx:i386 libglx0:i386 libsdl2-2.0-0:i386 steam-libs-i386:i386 libgl1:i386 libvdpau-va-gl1:i386 libva-glx2:i386 vdpau-driver-all:i386
lief der DU durch.
Neuinstallation von »libgl1-mesa-glx:i386« ging nicht:
Es existiert kein Installationskandidat
Hängt vermutlich am ganzen Steam-Kram, auf den kann ich auch zunächst verzichten bzw. Steam neu installieren.
Debian meint dazu:
QuotePaket: libgl1-mesa-glx (23.1.3-1) [debports]
Übergangspaket
Dieses Übergangspaket kann gefahrlos entfernt werden.
https://packages.debian.org/sid/libgl1-mesa-glx (https://packages.debian.org/sid/libgl1-mesa-glx)
edlin
Ich nutze seid jahren ausschliesslich LINUX. Heute hab ich mir mal wieder mein Arbeitssystem zerschossen (trotz --solver 3.0). Immerhin läuft mein backup nach wie vor stabil: Tumbleweed. Selbst Kleinigkeiten wie ein download von files aus signal (klappt nicht mehr unter debian-sid) funktionieren und das aktuelle desaster rund um libllvm und freunde sind bei Tumbleweed kein problem. Ich möchte keine werbung für Opensuse machen, aber Tumbleweed scheint mir ähnlich aktuell zu sein wie SID nur eben stabiler/verlässlicher. Übrigens: im debian-forum gibt es keine meldungen zu "unseren" problemen rund um libllvm und "fenstermanager". Wahrscheinlich kocht man dort den tee mit lauwarmen wasser und hält SID für teufelswerk.
Off topic:
Naja ... siduction ist nun mal zum einen ,,unstable" und zum zweiten ein Community-Projekt, deshalb wirst Du auf offiziellen Debiansites da auch wenig finden.
Debian stable (Bookworm) läuft z.B. noch auf apt.v.2.6. und hat den solver nicht, der erst mit 2.9. etabliert wurde.
Der Vorteil bei siduction ist halt die Aktualität, der verschmerzbare Nachteil eben der, das auch mal was ,,klemmt.
Ich hab mir auch schon oft mein System zerfranst ... aber mit etwas Geduld und Hilfe von hier kam alles wieder ins Lot.
Wer Sicherheit will, der sollte bei stable bleiben.
Sylvestre Ledru hat sich kurz zu Wort gemeldet:
QuoteYeah, it will be fixed in the next few days.
Doko wrote the fix but we are waiting for a build before uploading it
Quelle: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082495 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082495)
@ruebe99
Was heißt hier ,,trotz --solver 3.0"? Der Solver soll Paketabhängigkeiten und -konflikte erkennen und auflösen, damit uns apt einen Vorschlag für das Upgrade unterbreiten kann. Probleme, die erst bei der Installation auftreten werden, kann der Solver nicht erkennen, weder der alte, noch der neue. Daher meckert ja auch erst bei der Installation dpkg herum.
Ansonsten kurz belesen:
https://linuxnews.de/debian-erneuert-den-solver-in-apt/ (https://linuxnews.de/debian-erneuert-den-solver-in-apt/)
https://blog.jak-linux.org/2024/05/14/solver3/ (https://blog.jak-linux.org/2024/05/14/solver3/)
,,Tumbleweed scheint mir ähnlich aktuell zu sein wie SID nur eben stabiler/verlässlicher"
Tumbleweed kann ich nicht beurteilen, da ich sei
t Potato bei Debian geblieben bin.
Allerdings sollte man sich immer über den Status von Debian Sid/Unstable im Klaren sein:
https://www.debian.org/releases/sid/index.de.html (https://www.debian.org/releases/sid/index.de.html)
Einen schönen Restsonntag noch
edlin
Quote from: edlin on 2024/09/22, 12:04:43
Allerdings sollte man sich immer über den Status von Debian Sid/Unstable im Klaren sein:
https://www.debian.org/releases/sid/index.de.html (https://www.debian.org/releases/sid/index.de.html)
- Das kann ich nur unterstützen.
- Ich empfehle ausdrücklich siduction auf Btrfs zu installieren.
So bekommt man mit einem Rollback in nicht einmal 2 Minuten
(incl. Bedenkzeit) sein zuvor funktionsfähiges System zurück.
Dabei gilt es folgende Konfiguration zu berücksichtigen:
- Installation mit dem Bootmanager GRUB
Keine Auslagerung des /boot Verzeichnisses in ein Subvolumen oder eine Partition.
Anlegen eines /data Subvolumens anstatt eines /home Subvolumens.
Die privaten Daten nach /data auslagern und von /home verlinken.
Die Konfiguration der User bleibt unter /home und wird so von Systemsnapshots
erfasst und ist genauso schnell wieder herstellbar. - Wer später zu dem Bootmanager systemd-boot wechseln möchte
ESP (Efi System Partition) als erste Partition auf dem Medium
gdisk Typ "EF00", Größe 100MB reicht, VFAT formatiert, unter /efi eingehangen
XBOOTLDR Partition irgendwo auf dem gleichen Medium
gdisk Typ "EA00", Größe mind. 1GB, ext4 formatiert, unter /boot eingehangen
Wichtig: Diese Partition während der Installation nicht einhängen.
und natürlich die Systempartition mit Btrfs formatiert.
Ausführlichere Informationen findet ihr im siduction Handbuch unter
https://manual.siduction.org/ (https://manual.siduction.org/)
in den Kapiteln:
<Installation><Partitionierung von Installationsmedien>
<Systemadministration><Btrfs>
<Systemadministration><Snapper>
<Systemadministration><systemd-boot>
Ich verwende seit mehr als drei Jahren Btrfs und kann den nach Sid gelegentlich
hereinkommenden defekten Paketen absolut entspannt entgegensehen.
Der Hinweis auf BTFS ist wirklich gut. Nach mehr als 11 Jahren SID habe ich diverse Überraschungen erlebt. Gefühlt nehmen die Probleme wieder zu und ich frage mich, ob Projekte ohne Tests nach unfallfreiem Kompilieren deployen. Aber gut. Ich greife natürlich auf meine Arbeitsdaten sowohl von der Debian-Seite als auch von OpenSuSE aus zu. Ansonsten bleibe ich bei meinem Statement: Tumbleweed ist vergleichbar aktuell wie SID aber stabil.
ruebe99 (sine ira et studio)
@towo hat einen Fix bereitgestellt, der das Problem dann löst, wenn fixes in den /etc/apt/sources.list.d/ eingebunden ist.
Bei mir ist das die Datei fixes.list in o.g. Verzeichnis mit folgendem Inhalt:
deb https://ftp.gwdg.de/pub/linux/siduction/fixes unstable main contrib non-free non-free-firmware
Sachdienliche Hinweise finden sich im Handbuch:
https://manual.siduction.org/sys-admin-apt_en.html#sources.list---list-of-sources (https://manual.siduction.org/sys-admin-apt_en.html#sources.list---list-of-sources)
Bei mir lief danach ein apt update && apt full-upgrade sauber durch, keine Probleme nach dem Reboot.
Danke! Hat geklappt und alles ist wieder nice & easy!
to whom it may concern:
bei mir fehlte der key für "fixes"; daher:
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 15cbd88045c45076
Problem gelöst, danke an PIT, den Überbringer der Botschaft, und TOWO
Quote from: ruebe99 on 2024/09/22, 15:16:55
...
bei mir fehlte der key für "fixes"; daher:
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 15cbd88045c45076
Und was passierte da bei dir?
Bei mir:
# apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 15cbd88045c45076
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
Executing: /tmp/apt-key-gpghome.5UmqG9c26t/gpg.1.sh --keyserver keyserver.ubuntu.com --recv-keys 15cbd88045c45076
gpg: relative URL without a base
der key wird als trusted.gpd runtergeladen.
weil ich faul bin, habe ich trusted.gpd nach
/etc/apt/trusted.gpg.d/
verschoben. ist nicht nett (trusted.gpd..d ist eigentlich nicht für "freihändige" schlüssel vorgesehen), klappt aber. der nächste apt update sollte keinen schlüssel anmeckern - sonst auf ein neues mit dem angemeckerten schlüssel.
wird kein fehlender schlüssel angemeckert, dann braucht man auch nichts zu machen.
fixes.list in /etc/apt/sources.list.d ist ohne weitere action ok.
bei mir lief
apt update && apt full-upgrade ohne mecker durch.
Fixed in version llvm-toolchain-19/1:19.1.0-4
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082495 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082495)
apt policy libllvm19
libllvm19:
Installiert: 1:19.1.0-4
Installationskandidat: 1:19.1.0-4
edlin
hallo @scholle,
sorry, mir ist folgender Satz nicht klar:
QuoteAnlegen eines /data Subvolumens anstatt eines /home Subvolumens.
warum "anstatt" - mit ext4 lege ich immer
eine zusätzliche Partition /data für private Daten an mit Verlinkung zu /home
ist ähnliches mit btrfs nicht möglich ? also ein subvolume /home plus ein subvolume /data
ausserdem schreibst du:
QuoteDie Konfiguration der User bleibt unter /home
das verstehe ich so, dass ein /home-subvolume existiert ?
Danke für Aufklärung
Quote from: edlin on 2024/09/23, 08:00:15
Fixed in version llvm-toolchain-19/1:19.1.0-4
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082495 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082495)
...
edlin
Dann gehe ich mal davon aus, das ein
doas apt update && doas apt --solver 3.0 full-upgrade problemlos durchlaufen sollte. :)
Stefan
Quote from: hone on 2024/09/23, 09:38:25
sorry, mir ist folgender Satz nicht klar:
QuoteAnlegen eines /data Subvolumens anstatt eines /home Subvolumens.
warum "anstatt" - mit ext4 lege ich immer eine zusätzliche Partition /data für private Daten an mit Verlinkung zu /home
ist ähnliches mit btrfs nicht möglich ? also ein subvolume /home plus ein subvolume /data
Dann hast du eine Partition mit Btrfs und (mindestens) die Subvolumen @, @home, @data
und eine separate Partition mit ext4 für /data ??
Generell: Du kannst beliebig viele Subvolumen oder Partitionen anlegen.
Ich habe eine Empfehlung abgegeben und selbstverständlich ist es möglich
die Subvolumen @home und @data anzulegen und zu nutzen.
Quoteausserdem schreibst du:
QuoteDie Konfiguration der User bleibt unter /home
das verstehe ich so, dass ein /home-subvolume existiert ?
Das Ziel ist die privaten Daten vom System zu trennen. Dafür benötigst du kein
Subvolumen @home.
Wenn du die Subvolumen @, @home, @data nutzt, wird @home nicht von
automatischen snapshots des Subvolumen @ erfasst. Das musst du dann
für @home selbst konfigurieren und bei einem Rollback bleibt @home auch
außen vor. Also warum die doppelte Konfiguration für @ und @home, wenn
du die Daten eh nach @data auslagerst.
Das alles bezieht sich auf siduction mit der Basis debian Sid.
Regelmäßige Dist Upgrades sind selbstverständlich, mindestens wöchentlich,
viele machen dies täglich und einige mehrmals täglich.
Entsprechend der von mir empfohlenen Konfiguration ohne @home, wird dabei
das /home Verzeichnis bei jedem DU auch erfasst. Dann aber im wesentlichen
nur die Konfiguration des Benutzers und nicht seine umfangreiche Datensammlung.
Quote from: Isegrimm666 on 2024/09/23, 12:08:02
Quote from: edlin on 2024/09/23, 08:00:15
Fixed in version llvm-toolchain-19/1:19.1.0-4
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082495 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082495)
...
edlin
Dann gehe ich mal davon aus, das ein doas apt update && doas apt --solver 3.0 full-upgrade problemlos durchlaufen sollte. :)
Stefan
Hat geklappt ...
Danke an alle "human solver" :)
Stefan
btrfs kenne ich zu wenig - nutze bisher ext4 Formatierung
danke für die Erläuterung - es war mir nicht bekannt, dass das vom installer angelegte @home verzichtbar ist
QuoteEntsprechend der von mir empfohlenen Konfiguration ohne @home, wird dabei
das /home Verzeichnis bei jedem DU auch erfasst. Dann aber im wesentlichen
nur die Konfiguration des Benutzers
das ist ja der Hintergrund für ein subvolume oder Verzeichnis /data