FreeBSD4.10 Datenarchäologie... Problem...

holm

Well-Known Member
Moin,


Ich habe hier einen Rechner der jahrelang mit FreeBSD4.10 lief und squidproxy + mailserver etc bei einem Kunden spielte. Vorige Woche lag das Ding auf der Nase, medium-errors im log, Platte starb.. (30GB Fujitsu).
Aus diversen Gründen war es vorige Woche nicht "recht" das ich das Ding unter den Arm klemme und repariere..
für Backups war kein Geld übrig und für Erneuerung auch nicht, sonst liefe da kein 4.10...

Jetzt ist das Kind im Brunnen (war ja abzusehen) und ich versuche wenigstens die Gebeine zu retten..

Ich habe den Rechner noch booten können und mit dem vorhandenen OS noch eine 2. Platte im DD Mode gelabelt und die Filesysteme mit Tar durch eine Pipiline kopiert, nur habe ich da entweder was versaut oder das System war schon ausreichend kaputt.. hmm.

Das Ergebis ist ein Disklabel das vom Kern ignoriert wird, weil das Fake-Label mit den 50000 Blocks nicht anerkannt wird, der DD Mode wird also ignoriert, auch wenn ich den Kern booten kann.

Ich habe nun eine weitere Platte mit einer 4.9er Live-FS CD eingerichtet und möchte die Filesysteme rüber ziehen, seltsamerweise ergibt das aber auch Sauerkraut, ich habe mich wohl im Offset irgendwo vertan.

Wie finde ich den richtigen Beginn eines ffs heraus? Im Hexdump der Platte finde ich ab einem Offset von 0xd04 die Magic numbers fürs ffs.

00000cf0 20 00 00 50 68 94 37 00 00 e8 1e fe ff ff a1 f0 | ..Ph.7.........|
00000d00 3c 00 00 3d 54 19 01 00 74 1f 3d 19 01 54 19 75 |<..=T...t.=..T.u|
00000d10 2b 8b 04 9d 59 34 00 00 99 39 15 80 3b 00 00 75 |+...Y4...9..;..u|
00000d20 1b 39 05 7c 3b 00 00 75 13 a1 c4 37 00 00 3d 00 |.9.|;..u...7..=.|


#define FS_MAGIC 0x011954 /* the fast filesystem magic number */
#define FS_UFS1_MAGIC 0x011954 /* the fast filesystem magic number */
#define FS_UFS2_MAGIC 0x19540119 /* UFS fast filesystem magic number */

Ich hatte gedacht, mit dd nur den Filesysteminhalt auf ein geometrisch identisch großes Filesystem eienr anderen Platte zu kopieren, das habe ich gestern Abend schon gemacht, allerdings gabs da nach fsck immer nur ein Directory "lost+found" in dem sich der Inhalt in ziemlich unbrauchbarer Form befand..

Wie sieht der Beginn einer Platte wirklich aus, IMHO sollten da 16 Blöcke fürs disklabel reserviert sein und dort sollte dann das fs beginnen..?

Gruß,

Holm
 
Solange die Dateisysteme an sich es halbwegs überlebt haben, bekommt man das Kind noch aus dem Brunnen. Wie du sagst, musst du erst einmal herausfinden, wo das Dateisystem beginnt. Man kann es automatisch mit Tools wie "testdisk" probieren, aber bei UFS würde ich da doch eher zum manuellen Ansatz raten

Wenn es sich um ein UFS1-Dateisystem handelt, beginnt der Superblock 8 Kilobyte hinter dem Beginn der Partition. Bei UFS2 sind es 64 Kilobyte. Die Magic Number, über die man das Dateisystem identifizieren kann, liegt dann im letzten Feld des Superblocks. Für UFS1 ist es 0x011954 , für UFS2 0x19540119. Ich würde also die Platte vom Beginn an ablaufen und die Magic Number suchen. Dann von ihr aus zurückgehen (Länge des Superblocks + freier Speicher für den Bootcode), und so den Beginn der Partition identifizieren. Das Ende der Partition bekommt man über die Länge des Dateisystems, sie müsste im Superblock gespeichert sein, aber man braucht sie nicht zwingend.

Anschließend kann man mit gnop(8) für das System transparent aus der kompletten Festplatte die Partition ausschneiden. Also "gnop -o $offset_zum_beginn_der_partiton -s $länge_der_partiton ...", wobei man wie gesagt die Länge eigentlich nicht braucht. Dann ist das sich ergebende Device zwar zu lang, aber da UFS seine eigene Länge kennt, ist es egal. Zumindest ergibt sich nun ein neues Device, was der Partition entsprechen sollte. Man kann es also genauso behandeln, als sei es eine eine Festplatte mit UFS ohne Partition außen herum. Ich würde nun erst einmal mit fsck schauen, in welchem Zustand das Dateisystem ist. Also ist der Superblock in Ordnung (wenn nicht, kann man sich mit einem "trockenen" newfs-Lauf die Position der Superblock-Kopien ausrechnen lassen und eine dieser fsck mitgeben), ist das Dateisystem konsistent oder zumindest reparabel. Idealerweise kann man anschließend zumindest readonly mounten und die Daten herauskopieren. Wenn nicht, bleibt ein händischer Eingriff mit fsdb oder (das ist meist die bessere Wahl) unser Freund sysutils/ffs2recov.

Nachtrag (da jemand im IRC fragte): Für das Dateisystem selbst sollte(!) die Geometrie egal sein, zumindest wenn es nicht absolut steinalt ist.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: lme
...ist ja auch gaaanz einfach :-|

Das rootfs habe ich nun indessen schon retten können, bin im Prinzip so vorgegangen wie Yamagi vorgeschlagen hatte, nur war ich da schon fertig.
Jetzt operiert die Kiste an /usr herum, mal sehen wann die Kopiererei fertig wird..
auf jeden Fall wird mir der Geburtstag von Marshall Kirk McKusick wohl noch eine Weile in Erinnerung bleiben..

Gruß,

Holm
 
So... /usr ist indessen auch wieder da, /var läuft.. mann das dauert mit 4,4MB/sec trotzdem ne Ewigkeit..

Gruß,

Holm
 
Vielleicht verstaubt ja bei denen in irgendeiner Ecke noch so ein Computeropa und sie wollen mal ein nächtliches Backup installieren, was in so Fällen zumindest eine Menge Zeit, Geld und Nerven einspart?
 
Jo, genau so. Ich habe gerade, da das eh ein P2B-S Board mit SCSI ist, einen Tandberg SLR5 da eingebaut und das Ding dumpt gerade die Filesysteme...
Im Endeffekt ist nichts Wesentliches hops gegangen, die Kiste fühlt sich erst mal wieder wohl. (/bin war in die ewigen Jagdgründe eingegangen was noch ein Aufhalter war, ich habe halt die vorhandenen Sourcen da drauf neu übersetzt, was bis auf das verschwundene subdir "nslookup" unterhalb /usr/src/contrib/bind auch ganz gut ging.
Mehr zu machen lohnt nicht, ich werde eine neue Maschine vorschlagen, das ist ein 700Mhz P-III mit Asus Board. Die Kondensatoren da drauf machen aber mindestens noch mal so lange. Die Platte die ich da nun eingebaut habe stammt aus einem solchen Computeropa, ihre Schwester kämpft aber auch mit Medium-Errors.
Ich denke aber es ist Zeit mal über was Neues nachdenken zu lassen..

Gruß,

Holm
 
...warum schlägst Du mir das vor? Ich bin u.A. auch Händler, meinst Du ich habe was gegen Umsatz?
Der Kunde lebt von Kleingeld aus öffentlicher Hand...

Gruß,

Holm
 
Alleine der gesunde Menschenverstand sagt mir, dass veraltete, halbkaputte Hardware mit einem antiken Betriebssystem (EOL von 4.10 war wann, 2002?) eine bloede Idee ist.
 
Ich glaube wir alle, inclusive holm, wissen, dass es nicht optimal ist veraltete Hard- und Software einzusetzen wenn es Alternativen gibt. Da ihn das aber nicht weiter bringt und er sogar bereits dargelegt hat, dass er keinen direkten Einfluss darauf hat sollten wir es dabei belassen und versuchen ihm bei seinem Problem zu helfen. Danke
 
Völlig OT> Ich glaube ich habe das gleiche Board hier tatsächlich irgendwo in meiner Sammlung liegen oO - war damals afair in meinen 2. (damals schon gebrauchten) Arbeitsplatzrechner als Azubi verbaut ;) - da werden Erinnerungen wach :)
 
@ .not:
Du bist also Jemand der nach Jahren zum Kunden geht und dort die Rechner abschaltet weil deren OS EOL ist .. oder wie zwingst Du Kunden ohne Wartungsvertrag dazu die funktionierende alte Technik einfach mal so auszuwechseln, zumal wenn diese knapp bei Kasse sind?

Zeige mir übrigens eine aktuelle Hardware die diese Standzeit erreicht.

EOL 4.10: http://lists.freebsd.org/pipermail/freebsd-security/2006-May/003695.html

@Raktor: Danke fürs Verständnis, aber Probleme habe ich keine mehr. Das Ding steht wieder beim Kunden und wird noch so lange Dienst tun, bis ich den jetzt bestellten Ersatz geliefert habe.

Ich bin ja teilweise selber schuld das das Teil so lange lief, ich hatte in meiner ehemaligen Firma auf die Lieferung "anständiger" Hardware bestanden, Es wurde mal ein Netzteil gewechselt, sonst Nichts. Die Lieferfirma gibts nun schon lange nicht mehr, ich habe nun meine Eigne und darf nun auch neue Hard- und Software liefern.

Gruß,

Holm
 
Zurück
Oben