Hi,
gibt es eigentlich eine Art Recovery-Funktion im Debian-Paketmanagement? Ich habe halt einfach mal den Cache und die Liste installierter Pakete geloescht, um zu testen, ob und wenn ja wie er damit klarkommt. Ergebnis: gar nicht. Nun geht weniger als nichts, wenn ich das nicht irgendwie wiederherstellen kann.
bye, Rocco
On Tue, 13 Aug 2002 13:06:32 +0200, Rocco Rutte wrote:
gibt es eigentlich eine Art Recovery-Funktion im Debian-Paketmanagement? Ich habe halt einfach mal den Cache und die Liste installierter Pakete geloescht, um zu testen, ob und wenn ja wie er damit klarkommt. Ergebnis: gar nicht. Nun geht weniger als nichts, wenn ich das nicht irgendwie wiederherstellen kann.
Spiel einfach das Backup ein. SCNR.
Hast du vielleicht noch /var/backups/dpkg.status.*? Das sind alte /var/lib/dpkg/status was wohl das wichtigste File ist.
Reinhard
Hi,
* Reinhard Foerster [02-08-13 15:43:54 +0200] wrote:
On Tue, 13 Aug 2002 13:06:32 +0200, Rocco Rutte wrote:
gibt es eigentlich eine Art Recovery-Funktion im Debian-Paketmanagement? Ich habe halt einfach mal den Cache und die Liste installierter Pakete geloescht, um zu testen, ob und wenn ja wie er damit klarkommt. Ergebnis: gar nicht. Nun geht weniger als nichts, wenn ich das nicht irgendwie wiederherstellen kann.
Spiel einfach das Backup ein. SCNR.
Das waere eine Moeglichkeit... wenn ich eins haette. Das ist nur ein Spielrechner zum Frickeln ohne wichtige Sachen.
Hast du vielleicht noch /var/backups/dpkg.status.*? Das sind alte /var/lib/dpkg/status was wohl das wichtigste File ist.
Muss ich mal suchen.
bye, Rocco
Quoting Rocco Rutte s1118644@mail.inf.tu-dresden.de [ Tue, 13 Aug 2002 13:06:32 +0200 ] :
Debian-Paketmanagement? Ich habe halt einfach mal den Cache
Zwar vielleicht ein wenig unhandlich, aber bei mir läuft das bislang weitestgehend über die dpkg --get-selections respektive --set-selections - Schiene, um auf den Servers und Workstations, auf denen Debian läuft, zumindest den gegenwärtigen Paketinstallations-Stand wiederherzustellen. Ansonsten eben doch Backup. :)
Cheers, Kris
Am Dienstag, dem 13. August 2002 um 13:06:32, schrieb Rocco Rutte:
Ich habe halt einfach mal den Cache und die Liste installierter Pakete geloescht, um zu testen, ob und wenn ja wie er damit klarkommt.
Ich hätte an deiner Stelle den Test mit dem / Verzeichnis gemacht, dann hättest du die Antwort auch selbst herausgefunden. ;-)
Torsten
Hi,
* Torsten Werner [02-08-13 15:43:57 +0200] wrote:
Am Dienstag, dem 13. August 2002 um 13:06:32, schrieb Rocco Rutte:
Ich habe halt einfach mal den Cache und die Liste installierter Pakete geloescht, um zu testen, ob und wenn ja wie er damit klarkommt.
Ich hätte an deiner Stelle den Test mit dem / Verzeichnis gemacht, dann hättest du die Antwort auch selbst herausgefunden. ;-)
Backup, ich weiss. Von einem brauchbaren Paket-Management erwarte ich aber, dass es mit solchen Situationen klarkommt. Ausserdem beisst sich in dieser Situation die Katze irgendwie in den Schwanz, was man IMHO fixen sollte. Das Problem ist, dass er bei wichtigen Sachen (also libc, dpkg & co.) nur auf den Cache installierter Pakete schielt und nicht im geringsten prueft, was alles da ist (z.B. gibt es ein debconf-Binary, er meckert aber, dass debconf nicht installiert ist). Dieses Verhalten mag zwar Vorteile haben, aber auf den Cache _und_ installierte Binaries zu gucken, halte ich fuer intelligenter.
bye, Rocco
On Thu, 15 Aug 2002 17:07:57 +0200, Rocco Rutte wrote:
Ausserdem beisst sich in dieser Situation die Katze irgendwie in den Schwanz, was man IMHO fixen sollte.
Es wird immer einen Punkt geben, aber dem du keine weitere Daten löschen kannst ohne Informationen zu verlieren. Dieses "Problem" kannst du nicht fixen. Weil die dpkg.status so wichtig ist, werden ja schon massig backups vorgehalten (bei mir 8 Stück).
Ist /var komplett tot kann man anhand der Verzeichnisse in /usr/{share/}doc/ noch nachvollziehen, was installiert war. Letzlich sind die installierten Pakete aber gar nicht sooo wichtig. Hauptsache deine eigenen Daten sind noch da.
Das Problem ist, dass er bei wichtigen Sachen (also libc, dpkg & co.) nur auf den Cache installierter Pakete schielt und nicht im geringsten prueft, was alles da ist (z.B. gibt es ein debconf-Binary, er meckert aber, dass debconf nicht installiert ist).
Macht doch nix. Wenn du weißt, welche Pakete eigentlich installiert sind, kannst du genau diese Paket nochmal überbügeln und solltest so zu einem lauffähigen System kommen. Ich sehe nicht so recht, wie du dieses Verfahren wesentlich verbessern könntest.
aber auf den Cache _und_ installierte Binaries zu gucken, halte ich fuer intelligenter.
Das spart ein bischen Zeit gegenüber der Methode "alles blind überbügeln", ändert aber nichts am erreichbaren Ergebnis.
Reinhard
Hi,
* Reinhard Foerster [02-08-15 21:17:43 +0200] wrote:
Macht doch nix. Wenn du weißt, welche Pakete eigentlich installiert sind, kannst du genau diese Paket nochmal überbügeln und solltest so zu einem lauffähigen System kommen.
Sollte. Wenn alles weg ist, ist er der Meinung es waere nichts installiert, also auch keine glibc. Diese ist aber die Wurzel des Abhaengigkeitsbaumes der meisten Pakete. Um die glibc zu installieren, braucht es wieder andere Tools. Es sind laut der Datenbank aber keine installiert. Wenn ich jetzt erst debconf & co. installieren will, endet es wieder darin, dass er die glibc installieren will. Die Katze beisst sich in den Schwanz. Ich habe schon alle moeglichen Optionen probiert. Ergebnis: null. Er schafft nichteinmal das Ent- packen eines .deb-Paketes.
Ich sehe nicht so recht, wie du dieses Verfahren wesentlich verbessern könntest.
Zum Beispiel eine Art recovery-Funktion. D.h., er holt sich die Infos fuer Pakete und guckt dann, was da ist und was es sein koennte. Es wuerde aber wahrscheinlich zu lange dauern.
bye, Rocco
On Thu, 15 Aug 2002 21:34:27 +0200, Rocco Rutte wrote:
Sollte. Wenn alles weg ist, ist er der Meinung es waere nichts installiert, also auch keine glibc. Diese ist aber die Wurzel des Abhaengigkeitsbaumes der meisten Pakete. Um die glibc zu installieren, braucht es wieder andere Tools. Es sind laut der Datenbank aber keine installiert. Wenn ich jetzt erst debconf & co. installieren will, endet es wieder darin, dass er die glibc installieren will. Die Katze beisst sich in den Schwanz. Ich habe schon alle moeglichen Optionen probiert. Ergebnis: null. Er schafft nichteinmal das Ent- packen eines .deb-Paketes.
OK. Jetzt sehe ich, wo das Problem steckt. Das muß wirklich nicht sein. dpkg müßte irgendein Force-Flag haben, mit dem es mit aller Kraft versucht, ein Paket zu installieren solange die dafür nötigen Programme noch irgendwo in $PATH rumliegen.
Reinhard
Hallo,
On Thu, Aug 15, 2002 at 10:44:09PM +0200, Reinhard Foerster wrote:
On Thu, 15 Aug 2002 21:34:27 +0200, Rocco Rutte wrote:
Sollte. Wenn alles weg ist, ist er der Meinung es waere nichts installiert, also auch keine glibc. Diese ist aber die Wurzel des Abhaengigkeitsbaumes der meisten Pakete. Um die glibc zu installieren, braucht es wieder andere Tools. Es sind laut der Datenbank aber keine installiert. Wenn ich jetzt erst debconf & co. installieren will, endet es wieder darin, dass er die glibc installieren will. Die Katze beisst sich in den Schwanz. Ich habe schon alle moeglichen Optionen probiert. Ergebnis: null. Er schafft nichteinmal das Ent- packen eines .deb-Paketes.
OK. Jetzt sehe ich, wo das Problem steckt. Das mu? wirklich nicht sein. dpkg m??te irgendein Force-Flag haben, mit dem es mit aller Kraft versucht, ein Paket zu installieren solange die daf?r n?tigen Programme noch irgendwo in $PATH rumliegen.
Jetzt sehe ich auch, dass Rocco das Flag --force-depends sucht. Notfalls kann man dpkg mit einem Flag aufrufen, dass erstmal nur die Dateien auspackt aber noch nicht konfiguriert und hinterher per 'dpkg --configure --pending' die Konfiguration am Stueck versuchen.
Rocco, die Man-Page zu dpkg hast Du aber noch?
Holger
On 15.08.02 Rocco Rutte (s1118644@mail.inf.tu-dresden.de) wrote:
Moin,
Sollte. Wenn alles weg ist, ist er der Meinung es waere nichts installiert, also auch keine glibc. Diese ist aber die Wurzel des Abhaengigkeitsbaumes der meisten Pakete. Um die glibc zu installieren, braucht es wieder andere Tools. Es sind laut der Datenbank aber keine installiert. Wenn ich jetzt erst debconf & co. installieren will, endet es wieder darin, dass er die glibc installieren will.
Schon mal probiert, ein Pseudopaket zu installieren, was libc6 provided und selber keine Abhängigkeiten hate? Oder die Binaries von den Paketen einfach so in /usr/local zu verteilen wohl wissend, daß es richtig ist, was man da tut?
Die Katze beisst sich in den Schwanz. Ich habe schon alle moeglichen Optionen probiert. Ergebnis: null. Er schafft nichteinmal das Entpacken eines .deb-Paketes.
man ar.
Ich sehe nicht so recht, wie du dieses Verfahren wesentlich verbessern könntest.
Zum Beispiel eine Art recovery-Funktion. D.h., er holt sich die Infos fuer Pakete und guckt dann, was da ist und was es sein koennte. Es wuerde aber wahrscheinlich zu lange dauern.
Wie soll er denn sehen, zu welchem Paket die /lib/libc6.so gehört? -- also welches Paket mutmaßlich installiert ist.
H.
Hi,
* Hilmar Preusse [02-08-26 02:06:13 +0200] wrote:
On 15.08.02 Rocco Rutte (s1118644@mail.inf.tu-dresden.de) wrote:
Ich sehe nicht so recht, wie du dieses Verfahren wesentlich verbessern könntest.
Zum Beispiel eine Art recovery-Funktion. D.h., er holt sich die Infos fuer Pakete und guckt dann, was da ist und was es sein koennte. Es wuerde aber wahrscheinlich zu lange dauern.
Wie soll er denn sehen, zu welchem Paket die /lib/libc6.so gehört? -- also welches Paket mutmaßlich installiert ist.
Er koennte ja nicht Abhaengigkeiten an Paketen sondern an Dateien festmachen. Das koennte so aussehen, dass er beim Installieren eines Paketes guckt, ob libc6.so da ist. Wenn nicht, kann er mir ja eine Liste von Paketen anzeigen, die libc6.so enthalten und fragen, welches ich gern haette.
Dieses Konzept funktioniert zwar auch nur bis zu einem 'touch /lib/libc6.so', aber irgendwann ist immer Schluss...
bye, Rocco
Am Dienstag, dem 27. August 2002 um 15:09:49, schrieb Rocco Rutte:
Er koennte ja nicht Abhaengigkeiten an Paketen sondern an Dateien festmachen. Das koennte so aussehen, dass er beim Installieren eines Paketes guckt, ob libc6.so da ist. Wenn nicht, kann er mir ja eine Liste von Paketen anzeigen, die libc6.so enthalten und fragen, welches ich gern haette.
Du hast nicht erklärt, welche Vorteile das bringen soll. Außerdem, was machst du mit virtuellen Paketen?
z. B. Depends: mail-transport-agent
Torsten
Hi,
* Torsten Werner [02-08-27 16:20:35 +0200] wrote:
Am Dienstag, dem 27. August 2002 um 15:09:49, schrieb Rocco Rutte:
Er koennte ja nicht Abhaengigkeiten an Paketen sondern an Dateien festmachen. Das koennte so aussehen, dass er beim Installieren eines Paketes guckt, ob libc6.so da ist. Wenn nicht, kann er mir ja eine Liste von Paketen anzeigen, die libc6.so enthalten und fragen, welches ich gern haette.
Du hast nicht erklärt, welche Vorteile das bringen soll.
Ich halte es generell fuer die cleverere Variante eher nach vorhandenen Files als in einer Liste von installierten Paketen zu gucken. Das birgt zwar auch Stolperfallen; doch das haelt sich IMHO die Waage.
Außerdem, was machst du mit virtuellen Paketen?
z. B. Depends: mail-transport-agent
Abhaengigkeiten dieser Art halte ich fuer wenig sinnvoll. Es ist zwar der absolut idiotensichere Weg, aber wenn ich beispielsweise einen Mailclient installiere, folgt daraus noch nicht automatisch, dass ich auch einen MTA brauche.
bye, Rocco
Am Freitag, dem 30. August 2002 um 10:31:36, schrieb Rocco Rutte:
Ich halte es generell fuer die cleverere Variante eher nach vorhandenen Files als in einer Liste von installierten Paketen zu gucken.
Nach wie vor hast du nicht erklärt, was das für Vorteile bringen soll, außer dass es dir besser gefällt, was mir aber ein bisschen zu irrational ist.
Abhaengigkeiten dieser Art halte ich fuer wenig sinnvoll. Es ist zwar der absolut idiotensichere Weg, aber wenn ich beispielsweise einen Mailclient installiere, folgt daraus noch nicht automatisch, dass ich auch einen MTA brauche.
Okay, einige brauchen den aber unbedingt, andere geben sich mit Recommends und Suggests zufrieden. Aber das bestätigt doch eher, dass das Konzept gut ist.
Das Problem bleibt beispielsweise auch an anderer Stelle: lm-sensors empfiehlt die Installation des virtuellen Paketes lm-sensors-mod, welches konkret bei mir von lm-sensors-2.4.19 zur Verfügung gestellt wird. Hier reicht die Abhängigkeit von einer bestimmten Datei nicht aus usw. usf.
Torsten
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Friday 30 August 2002 10:31, Rocco Rutte wrote:
Ich halte es generell fuer die cleverere Variante eher nach vorhandenen Files als in einer Liste von installierten Paketen zu gucken. Das birgt zwar auch Stolperfallen; doch das haelt sich IMHO die Waage.
Ach? Wenn ich einen MTA brauche dann brauche ich ein Programm, das an Port 25/TCP lauscht. Wenn ich dann nach /usr/bin/sendmail suche kann das durchaus in die Hose gehen. Virtuelle Pakete sind unabhaengig von irgendeinem anderen Namespace, also fuer diesen Zweck robuster.
Außerdem, was machst du mit virtuellen Paketen?
z. B. Depends: mail-transport-agent
Abhaengigkeiten dieser Art halte ich fuer wenig sinnvoll. Es ist zwar der absolut idiotensichere Weg, aber wenn ich beispielsweise einen Mailclient installiere, folgt daraus noch nicht automatisch, dass ich auch einen MTA brauche.
Die meisten MUAs werden auch kein "depends" auf MTA haben. Ausserdem loest Du das Problem nicht mit File-dependencies (die wuerden nach sendmail suchen), sondern mit cleveren Package-Maintainern.
Im Uebrigen: RPM sucht entweder nach (echten) Paketen oder Files. Also nimm RPM, wenn Dir das besser gefaellt, oder schreib' was eigenes und schau, ob es sonst auch noch jemandem besser gefaellt.
In beiden Faellen muss ich Dich warnen: *RPM hat einige Design-Flaws, die nicht so ohne weiteres ausgebuegelt werden koennen (globaler Lock auf Package-DB, der leider auch ignoriert werden kann; binaere Codierung von Package-DB und non-standard Package-Codierung, d.h. nicht mit Standardtools (wie ar/tar) auszupacken). *In dpkg/dselect/apt steckt sehr viel Gehirnschmalz, das besser zu machen ist sehr schwer.
Zum Beginn dieses Threads: Mach Backups! (Oder stirb an den Folgen Deines (Nicht-)Handelns.) Jedes System hat seine Grenzen. Spaetestens, wenn Du den Magneten aus einem Lautsprecher (vorzugsweise aus einem Bassgitarrenverstaerker) ausbaust und auf die laufende Platte legst.
Konrad
PS.: manchmal liebe ich meinen fortune-sig-generator!
- --
"And I'm right. I'm always right, but in this case I'm just a bit more right than I usually am." -- Linus Torvalds, Sunday Aug 27, 2000.
Hallo Rocco,
On Thu, Aug 15, 2002 at 05:07:57PM +0200, Rocco Rutte wrote:
Hi,
- Torsten Werner [02-08-13 15:43:57 +0200] wrote:
Am Dienstag, dem 13. August 2002 um 13:06:32, schrieb Rocco Rutte:
Ich habe halt einfach mal den Cache und die Liste installierter Pakete geloescht, um zu testen, ob und wenn ja wie er damit klarkommt.
Wie Du jetzt hoffentlich gemerkt hast, kommt er nicht damit zurecht, dass die Statusdatenbank (/var/lib/dpkg/status) nicht mehr da ist. Der Cache (/var/cache/*) war wahrscheinlich unkritisch (das heisst Cache, weil die Information eben wiederbeschaffbar ist).
Ich h?tte an deiner Stelle den Test mit dem / Verzeichnis gemacht, dann h?ttest du die Antwort auch selbst herausgefunden. ;-)
Anderes Beispiel:
dd if=/dev/zero of=/dev/hda bs=512 count=1
und Du erwartest, dass er noch booten kann und die Partitionen wiederfindet? (Mal angenommen, eine IDE-Festplatte ist das Bootmedium) Ja, man kann die Partitionstabelle rekonstruieren (habe ich schon mal gemacht); ja, man kann maschinelle Unterstuetzung nutzen; nein, die Erkennung von Partitionsgrenzen anhand typischer Strukturen in den Filesystemen ist nicht 100%ig sicher und deshalb muss ein Mensch noch ein paar Informationen aus dem Gedaechtnis einfliessen lassen - oder ein _Backup_ des Bootsektors.
Backup, ich weiss. Von einem brauchbaren Paket-Management erwarte ich aber, dass es mit solchen Situationen klarkommt. Ausserdem beisst sich in dieser Situation die Katze irgendwie in den Schwanz, was man IMHO fixen sollte. Das
Tut sie nicht. In /var/lib/dpkg hat niemand etwas zu suchen, der nicht weiss was er tut. Wer dort Dateien aendert, muss eben damit rechnen, dass die Paketverwaltung aus dem Tritt kommt und bestenfalls manuell wieder halbwegs auf den richtigen Weg gebracht werden kann.
Problem ist, dass er bei wichtigen Sachen (also libc, dpkg & co.) nur auf den Cache installierter Pakete schielt und nicht im geringsten prueft, was alles da ist (z.B. gibt es ein debconf-Binary, er meckert aber, dass debconf nicht installiert ist). Dieses Verhalten mag zwar Vorteile haben, aber auf den Cache _und_ installierte Binaries zu gucken, halte ich fuer intelligenter.
Woher nimmst Du die Sicherheit, dass ein Binary namens foo im Paket 'foo' enthalten ist oder das Paket 'bar' ein Binary namens /usr/bin/bar mitbringt?
In der Paketdatenbank stehen uebrigens noch mehr Informationen als welche Pakete installiert sind. Die Abhaengigkeiten zwischen einzelnen Paketen sind fast nie aus den Binaries erkennbar, Shared Libraries sind da eine Ausnahme.
Uebrigens, falls Du noch /var/lib/dpkg/info hast, stehen dort noch Dateien rum, die ziemlich sicher ueber den Namen den Paketen zuzuordnen sind. Ob allerdings diese Dateien bei 'dpkg --remove' mit geloescht werden, kann ich nicht sagen.
Also, wenn ein System wirklich wichtig ist, machst Du _vor_ Aktionen mit unklaren Folgen ein Backup, OK?
Petri Heil
Holger
Hi,
* Holger Dietze [02-08-15 21:18:25 +0200] wrote:
On Thu, Aug 15, 2002 at 05:07:57PM +0200, Rocco Rutte wrote:
Problem ist, dass er bei wichtigen Sachen (also libc, dpkg & co.) nur auf den Cache installierter Pakete schielt und nicht im geringsten prueft, was alles da ist (z.B. gibt es ein debconf-Binary, er meckert aber, dass debconf nicht installiert ist). Dieses Verhalten mag zwar Vorteile haben, aber auf den Cache _und_ installierte Binaries zu gucken, halte ich fuer intelligenter.
Woher nimmst Du die Sicherheit, dass ein Binary namens foo im Paket 'foo' enthalten ist oder das Paket 'bar' ein Binary namens /usr/bin/bar mitbringt?
Von wichtigen Maschinen haelt man irgendwo die MD5-Pruef- summen von allen oeffentlichen ./bin- und ./lib-Verzeichnis- sen bereit. Darum ging es aber nicht. Wenn ich ein Paket installieren will, dass Programm A voraussetzt und fuer die Installation von A aber dieses Paket gebraucht wird, geht nichts mehr. Fuer den Fall, dass das Binary A da ist, kann er es ja suchen und eine Abfrage machen, ob ich dem vertrauen will. Das koennte ich mit einer Pruefsumme machen.
Also, wenn ein System wirklich wichtig ist, machst Du _vor_ Aktionen mit unklaren Folgen ein Backup, OK?
Das Paketmanagement ist nicht optimal designed und kommt recht einfach aus dem Tritt? Egal, alles neu machen und halt ein Backup einspielen?
bye, Rocco
On Thursday 15 August 2002 21:42, Rocco Rutte wrote:
Das Paketmanagement ist nicht optimal designed und kommt recht einfach aus dem Tritt? Egal, alles neu machen und halt ein Backup einspielen?
Du kannst die installierten Pakete jederzeit anhand von z.B. Contents-$arch.gz, welche auf jedem halbwegs ordentlichen Debian-Server (z.B. auf meinem ;) verfügbar ist, rekonstruieren. Je mehr an einem System verändert ist, desto risikoreicher wird das allerdings, da gerade 'unstable' im Moment seinem Namen alle Ehre macht und Dateien gern mal von Paket zu Paket wandern. Außerdem ist diese Datei im Normalfall nicht vom ftpmaster signiert, was ein weiteres theoretisches Problem darstellt.
Josef Spillner
Ich habe mir mal die Nachrichten aus dem Archiv geholt, damit ich auch ein bisschen mitdiskutieren kann...
Am Donnerstag, dem 15. August 2002 um 21:42:40, schrieb Rocco Rutte:
Das Paketmanagement ist nicht optimal designed und kommt recht einfach aus dem Tritt?
Hier hast du was nicht ganz verstanden - /var/lib/dpkg/ ist Teil des Paketmanagements, so sind die Programme /var/lib/dpkg/info/*.{pre,post}{rm,inst} ausführbarer Code. Wenn du den löscht, löscht du einen Teil des Paketmanagements und du kannst eben nicht davon ausgehen, das es irgendwie von alleine wieder auf die Beine kommt. Wie sollte das denn gehen?
Egal, alles neu machen und halt ein Backup einspielen?
Ein paar Tipps hast du doch bekommen. Du kannst dir auch erstmal mit einer Kopie von /var/lib/dpkg/ von einem anderen Rechner oder einer frischen Installation behelfen.
Torsten
lug-dd@mailman.schlittermann.de
-
Hilmar Preusse -
Holger Dietze -
Josef Spillner -
Konrad Rosenbaum -
Kristian Rink -
Reinhard Foerster -
Rocco Rutte -
Rocco Rutte -
Torsten Werner