Es gibt keinen Reparaturbefehl. Was passiert ist, ist, dass Ihr Downgrade die Version glibc
von einer aktuellen Version in eine ältere Version ersetzt hat und alle anderen Programme in Ihrem System, mit denen eine Verknüpfung hergestellt wird glibc
(dh alles außer den Paketen, die zuerst heruntergestuft wurden), die Symbole nicht finden können Sie müssen verbinden und ausführen.
Sie können dieses System reparieren, indem Sie ein Rettungssystem starten (OpenSUSE 11.1 Live-CD oder legen Sie die Festplatte in einen anderen Computer), laden Sie die richtige Version von glibc
rpm manuell herunter, entpacken Sie sie und legen Sie die Dateien manuell in das beschädigte System ein.
Sie können dies von fast jedem Linux-Betriebssystem aus tun, das das Dateisystem Ihres Servers einbinden kann. Die Hauptsache, die Sie benötigen, ist der rpm
Befehl, aber stellen Sie sicher, dass die Version von rpm
im Rettungssystem neu ist, so dass sie das LZMA-Archivformat unterstützt, das meines Erachtens zum Zeitpunkt der Veröffentlichung von 11.1 eingesetzt wurde. Der sicherste Weg, dies zu tun, ist die Verwendung der OpenSUSE / SUSE 11.1 Live-CD als Rettungssystem und nicht etwas Verrücktes und Altes wie Ubuntu 8.04 oder SUSE 10.
Sobald glibc wieder funktioniert, können Sie chroot
das defekte System erneut starten und das Downgrade erneut versuchen oder zurücksetzen. Wenn Sie nur in exit
der chroot-Umgebung auf Fehler stoßen, laden Sie die erforderlichen Pakete auf den Host herunter und entpacken sie in den Gast .
In der Tat ist es möglicherweise einfacher, eine OpenSUSE 11.1-Rettung zu starten, indem Sie einfach alle Dateien vom /usr
und /lib64
aus dem Rettungssystem in das defekte Root-Volume kopieren und alle Ihre Kernprogramme mit den Originalversionen (glibc, the) überschreiben Kernel, Xorg usw.). Aber überschreiben /boot
Sie nicht, sonst verlieren Sie Ihre menu.lst / menu.cfg. Überschreiben /etc
Sie nicht, sonst verlieren Sie fstab, was wichtig und wahrscheinlich nicht defekt ist (aber es wird brechen, wenn Sie es mit der Version auf der Rettungs-CD überschreiben).
Beachten Sie, dass dies nicht garantiert funktioniert. Sie möchten wahrscheinlich zypper up
(als root) im Rettungssystem laufen, BEVOR Sie dies tun. Dadurch werden alle Dateien in /usr
und /lib64
auf die neuesten Versionen des Aktualisierungs-Repositorys aktualisiert, bevor sie auf dem Server abgelegt werden. Dies bietet die beste Wahrscheinlichkeit, dass alles beim Booten in das defekte System funktioniert.
Höchstwahrscheinlich die Antwort auf Ihre Frage "Suse gebrochen?" ist wahrscheinlich "Ja", aber wenn Sie akribisch sind und wissen, was Sie tun, können Sie es trotzdem beheben. Es kann jedoch interessant sein, die rpm-Datenbank des defekten Systems davon zu überzeugen, dass alles in Ordnung ist.