Vor ein paar Tagen wollte ich meinem Media-PC mit Arch Linux mal auf den aktuellen Stand hieven. Bereits Anfang Juni habe ich schon gehört, dass das Paket glibc aktualisiert und der Pfad von /lib zu /usr/lib angepasst wurde. Damit ist dieser Fehler verbunden:
|
1 2 3 |
glibc: /lib exists in filesystem # oder glibc: /lib existiert im Dateisystem |
Am 14. Juli 2012 wurde diese News auf ArchLinux.org veröffentlich, man soll das Update mit diesen Befehlen ausführen:
|
1 2 |
pacman -Syu --ignore glibc pacman -Su |
Das hätte bestimmt auch funktioniert, aber wenn man über einen Monat später diese Aktualisierung machen möchte, muss man ein paar andere Befehle verwenden, um einige Probleme zu umgehen – jedenfalls in meinem Fall.
|
1 |
pacman -Syu --ignore glibc |
… hat bei mir mit diesen Meldungen abgebrochen:
|
1 2 3 4 5 6 7 8 9 |
warning: ignoring package glibc-2.16.0-2 warning: cannot resolve "glibc>=2.16", a dependency of "gcc-libs" warning: ignoring package glibc-2.16.0-2 warning: cannot resolve "glibc>=2.16", a dependency of "binutils" # oder Warnung: Ignoriere Paket glibc-2.16.0-2) Warnung: Kann "glibc>=2.16" nicht auflösen (eine Abhängigkeit von "gcc-libs") Warnung: Ignoriere Paket glibc-2.16.0-2) Warnung: Kann "glibc>=2.16" nicht auflösen (eine Abhängigkeit von "binutils") |
Man muss vorher ein …
|
1 |
pacman -Sd binutils gcc gcc-libs |
… ausführen, aber um Gottes willen nicht neu starten, sondern nun mit …
|
1 |
pacman -Syu --ignore glibc |
… alle Pakete außer glibc updaten – nun klappt es sogar ohne diese Warnungen. Jetzt sollte man ein …
|
1 |
pacman -Su |
… ausführen, aber der Paketmanager Pacman quittiert den Dienst mit:
|
1 |
pacman: /lib/libc.so.6 version GLIBC_2.16 not found (required by /usr/lib/libcurl.so.4) |
Am Besten kopiert man nun die von Pacman benötigten neuen curl Bibliotheken quick’n’dirty nach „/usr/lib“. (_arch_ muss je nach Architektur angepasst werden, meisten x86_64 oder i686)
|
1 2 3 4 5 6 7 8 9 |
cd /usr/lib grep ./ libcurl* mkdir /tmp/curl_backup/ mv libcurl.a libcurl.so libcurl.so.4 libcurl.so.4.2.0 /tmp/curl_backup cd /tmp/curl_backup wget tar -xJf curl-7.26.0-1-_arch_.pkg.tar.xz cd usr/lib cp *.* /usr/lib |
Nun klappt es auch mit …
|
1 |
pacman -Su |
Durch das stillose Reinkopieren der curl Libraries gibt es noch einen kleinen Fehler,
|
1 2 3 |
ldconfig: /lib/libcurl.so.4 is not a symbolic link # oder ldconfig: /lib/libcurl.so.4 ist kein symbolischer Link |
… ein …
|
1 |
pacman -S curl |
behebt das Problem. Jetzt noch ein Neustart und man kann sich über ein funktionierendes, aktuelles Arch Linux System freuen. 
Bei möglichen weiteren Problemen: Sollte die Systemaktualisierung dennoch mit dem Fehler …
|
1 |
glibc: /lib exists in filesystem |
… abbrechen, muss händisch nach dem Übeltäter gesucht werden – eine Anleitung findet man hier.
|
1 2 |
grep '^lib/' /var/lib/pacman/local/*/files find /lib -exec pacman -Qo -- {} + |
Quellen:
burrotinto.de – glibc: /lib existiert im Dateisystem
archlinux.de – glibc-Aktualisierung
archlinux.org – libc.so.6 version GLIBC_2.16 not found
Vielen Dank für den Beitrag, hat mir viele Stunde Frust erspart!
Wirklich hilfreich! Ging ohne Probleme!
Hi Nico,
vielen Dank. Nach Wochen nicht updaten rächt sich pacman gern ausgiebig:)
Weiter so!
Cassis
Vielleicht noch ein Hinweis:
Bei mir wurden mit cp *.* /usr/lib nicht die Symlinks mitkopiert, sondern neue Dateien angelegt. Da hat sich pacman das nächste Mal beschwert. Das Ergebnis muss nach Korrektur des Kopierens dann so aussehen:
Hi Cassis,
die Bibliotheken (libcurl.so.4.2.0 + libcurl.a) werden doch durch das Reinstallieren …
… ersetzt und die Symlinks gesetzt – oder irre ich mich?
Gruß
Hi Nico,
das hatte bei mir nicht geklappt. Manuell geht aber auch.
Hmm komisch, trotzdem danke für die Info. 😉
Bei mir musste ich das gleicher wie für curl auch für libarchive durchführen.