So, ich konnte gestern am "Abschlußjubel" nicht teilnehmen <g>, wg. @work...
Meine Gedanken zum Ablauf des Procederes im gesamten Thread
a) Ein leichter Anflug von "hätte ich mich nur nicht eingemischt..." ;-)
Der Aufwand für den/die/das Helfenden sind schon enorm, v.a. wenn es "remote" abläuft auf eine Art: Gib mir Info A, dann versuchen wir Kommando B, aber jetzt taucht mittendrin auch noch Problem C auf. Also muß sich vorher noch um Schritt A<->B<->C gekümmert werden. Gleichzeitig muß immer sichergestellt sein, daß das, was man vorschlägt auch "richtig" ist für die "entfernte" Gegebenheit. Deren "Zustand" man ja nur per "abgefragten Infos" kennt, aber nicht durch eigenes Betrachten(man sitzt nicht selbst an dem Rechner //Edit: Deshalb der irgendwann man geäußerte Wunsch: Ein Königreich für einen SSH-Zugang -> Suchmachine nach SSH wenn im Zusammenhang unklar).
Und ein/das Forum (mit all seinen technischen Erfordernissen ->Formatierungen, etc) ist bei einem "chatähnlichen" Vorgang mit dann ~270 Postings(!) auch nicht das "Yellow Of The Egg". Abgesehen von der Foren-Belastung/Belästigung.
*Ich* werde das wirklich so schnell nicht wieder tun ;-), alleine um keinen "Forenausschluß wg. Verstoß gegen Netiquette" zu riskieren <g>
b) Was der Thread IMHO hauptsächlich leistet (abgesehen von Ardbeg_'s persönlichem Nutzen) ist eine "Dokumentation" über eine Problembehandlung mittels Kenntnissen, Zielführung - und Möglichkeiten, wie sie m.E. nur(oder am einfachsten) unter UNIX-artigen Systemen möglich ist. Bitte nicht als Selbstbeweihräucherung verstehen, natürlich freue ich mich das sich *mein* Zeitaufwand auch gelohnt hat, aber die Möglichkeiten von Linux (und dann speziell auch Archlinux) bieten eben erst die Voraussetzungen für so ein Unterfangen.
Weiterhin: Mit entsprechenden Voraussetzungen dauert so ein Procedere natürlich keine "drei Tage". Selbst _Ardbeg_ wird - das gleiche Problem angenommen - zukünftig keine 3 Tage brauchen, um die Schritte im Thread dann nochmal "abzuarbeiten", anzuwenden.
Dem Ausweg einer "Neuinstallation" aus Hilflosigkeit bzw. dem "Ende der eigenen Möglickeiten" begegnet am am besten durch Vermehrung der eigenen Kenntnisse. Und: lerne in der Zeit, weil in der Not hast du keine Zeit...
_Ardbeg_ schrieb
Noch zwei Fragen on topic:
1. Wir haben ja jetzt wegen der fehlenden Information zu den Abhängigkeiten diverser Pakete diese als eigenständige Pakete installiert. Wenn nun ein Update für ein größere Programm kommt, werden dann dieses Abhängigkeiten erkannt?
2. Macht es Sinn die großen Pakete (KDE, Browser, KMail etc.) neu zu installieren, falls wir etwas doch nicht erwischt haben sollten?
Zu 1) AFAIK Nein, etwas war wir jetzt als explizit installiert haben behält auch diesen Status. An der Funktionalität bzw. für zukünftige Updates tut das nichts zur Sache. Das würde nur für Deinstallationen eine Rolle spielen, da dann ggf. Pakete als "Waisenkinder" übrigbleiben. Diese könnte man dann ggf. mit pacman -Qt ermitteln, (theoretisch: diese Liste abzüglich der Pakete die man explizit installiert hat bzw. die man "braucht" ergibt die Pakete, die eigentlich "wegkönnten").
Zu 2) Ich denke, denn größten Teil müßten wir im Verlauf eigentlich erwischt haben. Auf jedenfall die, die für das grundlegende System (Boot z.B.) absolut notwendig sind. Ich würde jetzt evtl. notwendige Nacharbeiten eher davon abhängig machen, wenn bestimmte von dir genutzte Programme oder Vorgänge nicht mehr (richtig) funktionieren. Also alle notwendigen Dinge austesten.
Als Beispiel: Irgendwann gegen Ende hatten wir festgestellt, daß für libreoffice in der lokalen Datenbank lediglich nur noch die deutsche Sprach/Locale-Datei eingetragen war als installiertes Paket, aber das eigentliche libreoffice Basispaket nicht mehr. Das hättest du nun festgestellt wenn du versucht hättest Libreoffice zu starten. Wobei: Selbst das Starten hätte aktuell noch funktionieren können, libroffice war ja noch installiert (nur nicht in der lokalen DB vorhanden). "Irgendwann" wäre es aber zu 100% *nicht* mehr gestartet. D.h.: auch die künftigen Wochen/Monate kann es immer nochmal zu "Nachfolgeauffälligkeiten" kommen, die dann ggf. einen Eingriff erfordern.
Abgesehen vom einfachen "Ausprobieren" kannst du auch einfach mal die Liste der jetzt explizit installierten Pakete (pacman -Qe) durchgehen und anhand der Paketnamen entscheiden, ob irgendwas "Wichtiges" fehlt. Die Paketnamen weisen ja meistens namenlich auf die Funktion hin; wenn der Firefox als Browser nicht mehr drin wäre wüßte man ganz klar: Hoppla, den will/muß ich doch haben, also Reinstallation (um ihn wieder in der lokalen Paketdatenbank drin zu haben).
Noch eine Anmerkung zu dem, wie wir während des Threads mit pacman umgegangen sind:
Wir haben oft Pakete "einzeln" installiert mittels pacman -S (plus Optionen) <paketnamen> installiert. Das ist für den Normalfall (und für Normaluser) eigentlich ein absolutes No-Go. Im Normalfall sollten Pakete *immer* im Zuge eines gleichzeitigen Systemupdates (neu/re)installiert werden um ein inkonsistentes Gesamtsystem zu vermeiden.
Siehe auch:
https://wiki.archlinux.org/index.php/System_maintenance#Partial_upgrades_are_unsupported
Wir haben während des Threads solch eine Inkonsistenz aber bewußt in Kauf genommen, da unser Anliegen zu der Zeit die Wiederherstellung der lokalen DB war.
Dein übliches Verfahren für neue bzw. für zu reinstallierende Pakete sollte immer ein:
pacman -Syu <paketnamen> sein. Sich gerade bei pacman (als zentralen Bestandteil des Archlinux-Systems) mit den Wiki-Einträgen dazu zu beschäftigen ist IMHO eine Grundbedingung. Das englische Wiki auf .org ist da (nutzerbedingt) die meist aktuellere und informativere Anlaufstelle.
Weiterhin der (offene) Punkt mit dieser Haskell-Modul Fehlermeldung:
Da habe ich aktuell kein Wissen/Möglichkeit, dem auf den Grund zu gehen. Wenn pacman weiterhin je nach Situation diese Meldungen zeigt, dann mache ggf. dazu einen speziellen Thread auf, evtl. kennt ja jemand eine Lösungsmethode. Diese ganzen Haskell-Compiler/Module hast du ja sicher als Abhängigkeit für irgendwas von KDE bekommen. Ein möglicher Ansatz wäre daher: Im pacman.log rausfinden, welcher Vorgang (welche !explizite!Paketinstallation) das oder die ersten Haskell-Module nachgezogen haben. Dann alles von Haskell deinstallieren plus das explizite Paket, welches ursprünglich das Nachziehen auslöste. Danach dieses explizite Programm wieder installieren (und pacman sich um den hoffentlich dann wieder funktionierenden "Rest" kümmern lassen. Das Tool pactree aus dem Paket pacman-contrib kann beim Rausfinden/Darstellen von Abhängigkeitsverläufen hilfreich sein.
Noch was "Praktisches" zum Schluß: Du hast selbst gesehen wie wichtig für Archlinux eine intakte lokale Paketdatenbank ist. Und mit einer "richtigen" Liste der früher bei dir installierten Pakete hätten wir uns manch "kruden Umweg" ersparen können. Da werfe ich doch einfach mal das Zauberwort "Backup" ein, da - profan gesagt - eigentlich für alle "Daten" gilt: Kein Backup? Kein Mitleid!
Während des Threads haben wir uns einige Male den damaligen Zustand von /etc und /var/lib/pacman/local als Archiv gesichert, damals "nur" um ggf. wieder zur anfänglichen "kaputten Situation" zurückkehren zu können wenn wir bei der Reparatur nochmehr kaputt gemacht hätten. Warum also nicht den "Gedanken denken": Hej, mache ich doch mal eine Sicherung von sowas an einem Zeitpunkt, wenn alles (noch) OK ist...
Ich persönlich habe ein kleines Skript, welches ich per Hand periodisch oder vor "Aktionen" einfach starte. "Aktionen" kann dann auch ein normales pacman -Syu sein. Das Skript sichert mir bestimmte Dinge des Systems, die durch "Aktion" ggf. in Mitleidenschaft geraten könnten. Dort packe ich alles rein, was mir für mein Linux-System wichtig ist (Bsp: /etc, Paketdatenbank, Logfiles, div. anderes).
Bei mir heißt das Skript versicherung.sh und sieht in der Basisversion so aus:
#!/bin/sh
#
# Ablageort
DEST=/var/local/versicherung
WORK="$DEST"/$(/usr/bin/date +%F_%X)
mkdir -p $WORK
echo -e "Sichere nach $WORK:"
# Bootloader Konfig
echo -e "\n----> Sichere aktuelle Bootloader-Konfigdatei"
#cp -a /boot/syslinux/syslinux.cfg $WORK/
cp -a /boot/grub/grub.cfg $WORK/
# Partitionstabellen zur Wiederherstellung mit sfdisk (man sfdisk)
echo -e "\n----> Sichere Partitionstabellen"
mkdir -p $WORK/blockdevices
sfdisk --dump /dev/sda > $WORK/blockdevices/sfdisk_sda.dump
sfdisk --dump /dev/sdb > $WORK/blockdevices/sfdisk_sdb.dump
lsblk -f > $WORK/blockdevices/lsblk.list
# /etc in Archiv sichern
echo -e "\n----> Sichere /etc..."
tar --totals -cpzf $WORK/etc.tar.gz /etc
# pacman: Logfile und /var/lib/local
echo -e "\n----> Sichere pacman.log und Status der installierten Pakete"
mkdir -p $WORK/pacman_infos
cp -a /var/log/pacman.log $WORK/pacman_infos/
pacman -Q > $WORK/pacman_infos/Q_gesamt_paketliste
pacman -Qe > $WORK/pacman_infos/Qe_explizit_paketliste
pacman -Qd > $WORK/pacman_infos/Qd_abhaengigkeiten_paketliste
tar --totals -cpzf $WORK/pacman_infos/var_lib_pacman_local.tar.gz /var/lib/pacman/local
# diverse nuetzliche Logfiles
echo -e "\n----> Sichere diverse Logfiles"
mkdir -p $WORK/div_logs
dmesg > $WORK/div_logs/dmesg
journalctl -b > $WORK/div_logs/journal_letzer_boot
# Xorg.log, normalerweise unter /var/log
cp -a /var/log/Xorg*.log $WORK/div_logs/
# anderes, z.B. ein root-journalheft in dem Aenderungen
# am System dokumentiert sind
###echo -e "\n----> Eigene Dinge"
###cp -a /root/ws01_changelog $WORK/
#
echo -e "\n\aIch habe fertig! Jetzt lass uns was kaputt machen..."
(Muß latürnich an eigene Gegebenheiten (Platten,Bootloader angepaßt werden)
Als root ausgeführt sichert es mir einfachst alle Dinge, die mir für mein System zur Reparatur oder Wiederherstellung zeitnah wichtig erscheinen - abseits von einer "richtigen" Daten- und/oder System-Backup(und Recovery!)-Strategie, was so ein Skript allenfalls ergänzt. Letztlich verfügbar muß /var/local/versicherung/* natürlich außerhalb des aktuellen System sein, sonst: "Wie macht der Esel? iah, iah"...
Hätten wir im/vor dem Thread z.B. eine Kopie der pacman-DB gehabt, dann wären so etwa 200 der Postings hier nicht erforderlich gewesen. Oder: die Liste der als explizit installierten Pakete. Hätten wir einfach an pacman verfüttern können, der hätte sich dann um die (Re)installation dieser Pakete (und deren evtl. Abhängigkeiten) kümmern können - und voilá...
Selbst eine "Neuinstallation" aus (zeit)ökonomischer Sicht wäre dann keine Neuinstallation aus "Hilflosigkeit", sondern eigentlich was "Geplantes". Partitionen ggf. wiederherstellen/anlegen, Liste der explizit installierten Pakete an pacstrap bzw. pacman verfüttern, /etc zurückspielen, Bootloader restauriern/anpassen -> Booten und fertig.... Kuchen für alle!
So, auch das ist wieder länger geraten als ich erst vorhatte...