zpool import führt zu kernel panic

R

ret

Active Member
Hallo,

einer meiner zfs pool lässt sich nicht mehr importieren. Bei jeglichem Versuch stürtzt das System :(
Der Pool besteht aus einer 160GB SATA-HDD und wurde unter FreeBSD 10.0-RELEASE-p7 genutzt. Ich habe daraufhin mit dd ein Image der Festplatte (einige Sektoren waren nicht mehr lesbar) erstellt, doch auch dieses führt beim Importversuch zum Systemabsturz.

Ich hoffe ihr könnt mir ein paar Tipps geben, wo ich eventuell ansetzen kann, noch einige Daten zu retten.

Gruß

ret
 

Anhänge

  • zfs_import_panic.webp
    zfs_import_panic.webp
    120,5 KB · Aufrufe: 473
Den Link werde ich mir mal ansehen. Danke!

joergpc schrieb:
Bootest du mit einer live CD und welche Version.
Zum Vergrößern anklicken....
Der Screenshot ist vom System selbst, also er fängt an zu booten und beim mounten den zfs pools stürtzt das zfs Kernelmodul ab.
Das dd-Image habe ich mit mfsbsd über PXE gebootet erstellt.
 
Je nachdem, welche Sektoren in Fritten sind, weiß der liebe Herrgott alleine, was da passiert.
Die Herrschaften, die sich bei FreeBSD um das ZFS kümmern, freuen sich aber sicherlich über eine Nachricht mit fundierten Details.
 
peterle schrieb:
Je nachdem, welche Sektoren in Fritten sind, weiß der liebe Herrgott alleine, was da passiert.
Die Herrschaften, die sich bei FreeBSD um das ZFS kümmern, freuen sich aber sicherlich über eine Nachricht mit fundierten Details.
Zum Vergrößern anklicken....

Hallo Peterle,

hast du ne Ahnung wohin ich mich am teffendsten wenden sollte?

Mailingliste/Forum, welches?

Danke

Gruß

ret
 
Klar.

Code: 
mdconfig -t vnode -f  zfspool.dd -u 0

zpool import -R /test tank0

auch die readonly Variante wie im Link von TCM beschrieben lässt den Rechner abstürzen

Code: 
zpool import -N -o readonly=on -f -R /test tank0
 
peterle schrieb:
Ich würde es mal mit einer Mailingliste versuchen, da Du es scheinbar nicht auf ein sinnvolles Ticket runterbrechen kannst.
Bugs bietet sich doch an oder?
Zum Vergrößern anklicken....
Lieber freebsd-fs@, denn das ist ja die UFS und ZFS Liste. Aber allzu große Hoffnungen würde ich mir auch da nicht machen. ZFS ist sehr robust, aber wenn ihm etwas durch seine Metadaten schießt - was bei intakter Hardware nicht passieren kann oder zumindest nicht sollte - reagiert es äußert allergisch.
 
Hallo,

ich werde mal mein Glück versuchen. Danke für die Hinweise.

Die Originalplatte lebt noch, allerdings ist sie nicht mehr komplett lesbar. Deshalb hatte ich das dd-Image angefertigt.

Was IMHO nicht passieren darf, ist dass die ganze Maschine aufgrund der (korrupten) ZFS-Datenbasis abstürzt. Das sollte durch eine Fehlermeldung abgefangen sein.

Nicht ganz verstanden habe ich diese Transaktionseinträge und ob man da evtl. etwas machen kann, damit das FS nochmal gemounted und die vorhanden Daten ausgelesen werden können.

Welche transaction id sollte ich verwenden?

Code: 
zdb -ul /dev/md0

Liefert am Anfang und Ende evtl. einen Hinweis (ich fürchte der bedeutet nichts Gutes :/)
Code: 
--------------------------------------------
LABEL 0
--------------------------------------------
failed to unpack label 0
--------------------------------------------
LABEL 1
--------------------------------------------
failed to unpack label 1
--------------------------------------------
LABEL 2
--------------------------------------------

(...)

--------------------------------------------
LABEL 3
--------------------------------------------
failed to unpack label 3

Die gesamte Ausgabe sieht wie folgt aus:
Code: 
--------------------------------------------
LABEL 0
--------------------------------------------
failed to unpack label 0
--------------------------------------------
LABEL 1
--------------------------------------------
failed to unpack label 1
--------------------------------------------
LABEL 2
--------------------------------------------
failed to unpack label 2
Uberblock[81]
magic = 0000000000bab10c
version = 5000
txg = 105137536
guid_sum = 4388488694021597985
timestamp = 1413202065 UTC = Mon Oct 13 14:07:45 2014
Uberblock[82]
magic = 0000000000bab10c
version = 5000
txg = 105137537
guid_sum = 4388488694021597985
timestamp = 1413202072 UTC = Mon Oct 13 14:07:52 2014
Uberblock[83]
magic = 0000000000bab10c
version = 5000
txg = 105137538
guid_sum = 4388488694021597985
timestamp = 1413202074 UTC = Mon Oct 13 14:07:54 2014
Uberblock[84]
magic = 0000000000bab10c
version = 5000
txg = 105137539
guid_sum = 4388488694021597985
timestamp = 1413202075 UTC = Mon Oct 13 14:07:55 2014
Uberblock[85]
magic = 0000000000bab10c
version = 5000
txg = 105137540
guid_sum = 4388488694021597985
timestamp = 1413202079 UTC = Mon Oct 13 14:07:59 2014
Uberblock[86]
magic = 0000000000bab10c
version = 5000
txg = 105137541
guid_sum = 4388488694021597985
timestamp = 1413202087 UTC = Mon Oct 13 14:08:07 2014
Uberblock[87]
magic = 0000000000bab10c
version = 5000
txg = 105137542
guid_sum = 4388488694021597985
timestamp = 1413202093 UTC = Mon Oct 13 14:08:13 2014
Uberblock[88]
magic = 0000000000bab10c
version = 5000
txg = 105137543
guid_sum = 4388488694021597985
timestamp = 1413202095 UTC = Mon Oct 13 14:08:15 2014
Uberblock[89]
magic = 0000000000bab10c
version = 5000
txg = 105137544
guid_sum = 4388488694021597985
timestamp = 1413202097 UTC = Mon Oct 13 14:08:17 2014
Uberblock[90]
magic = 0000000000bab10c
version = 5000
txg = 105137545
guid_sum = 4388488694021597985
timestamp = 1413202100 UTC = Mon Oct 13 14:08:20 2014
Uberblock[91]
magic = 0000000000bab10c
version = 5000
txg = 105137546
guid_sum = 4388488694021597985
timestamp = 1413202106 UTC = Mon Oct 13 14:08:26 2014
Uberblock[92]
magic = 0000000000bab10c
version = 5000
txg = 105137547
guid_sum = 4388488694021597985
timestamp = 1413202107 UTC = Mon Oct 13 14:08:27 2014
Uberblock[93]
magic = 0000000000bab10c
version = 5000
txg = 105137548
guid_sum = 4388488694021597985
timestamp = 1413202108 UTC = Mon Oct 13 14:08:28 2014
Uberblock[94]
magic = 0000000000bab10c
version = 5000
txg = 105137549
guid_sum = 4388488694021597985
timestamp = 1413202113 UTC = Mon Oct 13 14:08:33 2014
Uberblock[95]
magic = 0000000000bab10c
version = 5000
txg = 105137550
guid_sum = 4388488694021597985
timestamp = 1413202119 UTC = Mon Oct 13 14:08:39 2014
Uberblock[96]
magic = 0000000000bab10c
version = 5000
txg = 105137551
guid_sum = 4388488694021597985
timestamp = 1413202123 UTC = Mon Oct 13 14:08:43 2014
Uberblock[97]
magic = 0000000000bab10c
version = 5000
txg = 105137552
guid_sum = 4388488694021597985
timestamp = 1413202125 UTC = Mon Oct 13 14:08:45 2014
Uberblock[98]
magic = 0000000000bab10c
version = 5000
txg = 105137553
guid_sum = 4388488694021597985
timestamp = 1413202125 UTC = Mon Oct 13 14:08:45 2014
Uberblock[99]
magic = 0000000000bab10c
version = 5000
txg = 105137554
guid_sum = 4388488694021597985
timestamp = 1413202130 UTC = Mon Oct 13 14:08:50 2014
Uberblock[100]
magic = 0000000000bab10c
version = 5000
txg = 105137555
guid_sum = 4388488694021597985
timestamp = 1413202135 UTC = Mon Oct 13 14:08:55 2014
Uberblock[101]
magic = 0000000000bab10c
version = 5000
txg = 105137556
guid_sum = 4388488694021597985
timestamp = 1413202144 UTC = Mon Oct 13 14:09:04 2014
Uberblock[102]
magic = 0000000000bab10c
version = 5000
txg = 105137557
guid_sum = 4388488694021597985
timestamp = 1413202150 UTC = Mon Oct 13 14:09:10 2014
Uberblock[103]
magic = 0000000000bab10c
version = 5000
txg = 105137558
guid_sum = 4388488694021597985
timestamp = 1413202158 UTC = Mon Oct 13 14:09:18 2014
Uberblock[104]
magic = 0000000000bab10c
version = 5000
txg = 105137559
guid_sum = 4388488694021597985
timestamp = 1413202165 UTC = Mon Oct 13 14:09:25 2014
Uberblock[105]
magic = 0000000000bab10c
version = 5000
txg = 105137560
guid_sum = 4388488694021597985
timestamp = 1413202173 UTC = Mon Oct 13 14:09:33 2014
Uberblock[106]
magic = 0000000000bab10c
version = 5000
txg = 105137561
guid_sum = 4388488694021597985
timestamp = 1413202176 UTC = Mon Oct 13 14:09:36 2014
Uberblock[107]
magic = 0000000000bab10c
version = 5000
txg = 105137562
guid_sum = 4388488694021597985
timestamp = 1413202180 UTC = Mon Oct 13 14:09:40 2014
Uberblock[108]
magic = 0000000000bab10c
version = 5000
txg = 105137563
guid_sum = 4388488694021597985
timestamp = 1413202187 UTC = Mon Oct 13 14:09:47 2014
Uberblock[109]
magic = 0000000000bab10c
version = 5000
txg = 105137564
guid_sum = 4388488694021597985
timestamp = 1413202193 UTC = Mon Oct 13 14:09:53 2014
Uberblock[110]
magic = 0000000000bab10c
version = 5000
txg = 105137565
guid_sum = 4388488694021597985
timestamp = 1413202195 UTC = Mon Oct 13 14:09:55 2014
Uberblock[111]
magic = 0000000000bab10c
version = 5000
txg = 105137566
guid_sum = 4388488694021597985
timestamp = 1413202196 UTC = Mon Oct 13 14:09:56 2014
Uberblock[112]
magic = 0000000000bab10c
version = 5000
txg = 105137567
guid_sum = 4388488694021597985
timestamp = 1413202200 UTC = Mon Oct 13 14:10:00 2014
Uberblock[113]
magic = 0000000000bab10c
version = 5000
txg = 105137568
guid_sum = 4388488694021597985
timestamp = 1413202209 UTC = Mon Oct 13 14:10:09 2014
Uberblock[114]
magic = 0000000000bab10c
version = 5000
txg = 105137569
guid_sum = 4388488694021597985
timestamp = 1413202217 UTC = Mon Oct 13 14:10:17 2014
Uberblock[115]
magic = 0000000000bab10c
version = 5000
txg = 105137570
guid_sum = 4388488694021597985
timestamp = 1413202223 UTC = Mon Oct 13 14:10:23 2014
Uberblock[116]
magic = 0000000000bab10c
version = 5000
txg = 105137571
guid_sum = 4388488694021597985
timestamp = 1413202224 UTC = Mon Oct 13 14:10:24 2014
Uberblock[117]
magic = 0000000000bab10c
version = 5000
txg = 105137572
guid_sum = 4388488694021597985
timestamp = 1413202226 UTC = Mon Oct 13 14:10:26 2014
Uberblock[118]
magic = 0000000000bab10c
version = 5000
txg = 105137573
guid_sum = 4388488694021597985
timestamp = 1413202230 UTC = Mon Oct 13 14:10:30 2014
Uberblock[119]
magic = 0000000000bab10c
version = 5000
txg = 105137574
guid_sum = 4388488694021597985
timestamp = 1413202237 UTC = Mon Oct 13 14:10:37 2014
Uberblock[120]
magic = 0000000000bab10c
version = 5000
txg = 105137575
guid_sum = 4388488694021597985
timestamp = 1413202242 UTC = Mon Oct 13 14:10:42 2014
Uberblock[121]
magic = 0000000000bab10c
version = 5000
txg = 105137576
guid_sum = 4388488694021597985
timestamp = 1413202243 UTC = Mon Oct 13 14:10:43 2014
Uberblock[122]
magic = 0000000000bab10c
version = 5000
txg = 105137577
guid_sum = 4388488694021597985
timestamp = 1413202244 UTC = Mon Oct 13 14:10:44 2014
Uberblock[123]
magic = 0000000000bab10c
version = 5000
txg = 105137578
guid_sum = 4388488694021597985
timestamp = 1413202248 UTC = Mon Oct 13 14:10:48 2014
Uberblock[124]
magic = 0000000000bab10c
version = 5000
txg = 105137579
guid_sum = 4388488694021597985
timestamp = 1413202253 UTC = Mon Oct 13 14:10:53 2014
Uberblock[125]
magic = 0000000000bab10c
version = 5000
txg = 105137580
guid_sum = 4388488694021597985
timestamp = 1413202255 UTC = Mon Oct 13 14:10:55 2014
Uberblock[126]
magic = 0000000000bab10c
version = 5000
txg = 105137581
guid_sum = 4388488694021597985
timestamp = 1413202256 UTC = Mon Oct 13 14:10:56 2014
Uberblock[127]
magic = 0000000000bab10c
version = 5000
txg = 105137582
guid_sum = 4388488694021597985
timestamp = 1413202260 UTC = Mon Oct 13 14:11:00 2014
--------------------------------------------
LABEL 3
--------------------------------------------
failed to unpack label 3
 
Yamagi schrieb:
Lieber freebsd-fs@, denn das ist ja die UFS und ZFS Liste. Aber allzu große Hoffnungen würde ich mir auch da nicht machen. ZFS ist sehr robust, aber wenn ihm etwas durch seine Metadaten schießt - was bei intakter Hardware nicht passieren kann oder zumindest nicht sollte - reagiert es äußert allergisch.
Zum Vergrößern anklicken....

Trotzdem sollte das nicht den Kernel killen, wenn der nicht auf genau dieser Platte liegt oder?
 
Hi @ret.

Nimm mal ein aktuelles Illumios live system und importiere den Pool.
Eventuell klappt es damit auf den Pool read-only zuzugreifen.
Bei mir hat das schon mal funktioniert. Pool war unter FBSD nicht lesbar (kernel panic) und unter illumios read-only wenigsten noch lesbar
 
Bei Post #16 ist mir ein Fehler unterlaufen.

Den zdb Befehl muss man natürlich auf die zfs-partition anwenden.

Dann kommen keinen Fehlermeldungen sondern folgende Ausgabe.

Könnt ihr damit was anfagen, welche Transaktionsnummer ich beim zpool import angeben soll?

Code: 
zdb -ul /dev/md0p3
--------------------------------------------
LABEL 0
--------------------------------------------
    version: 5000
    name: 'tank0'
    state: 0
    txg: 105130456
    pool_guid: 16431622310954249022
    hostname: ''
    top_guid: 6403610456776900579
    guid: 6403610456776900579
    vdev_children: 1
    vdev_tree:
        type: 'disk'
        id: 0
        guid: 6403610456776900579
        timestamp = 1413202040 UTC = Mon Oct 13 14:07:20 2014
Uberblock[123]
        magic = 0000000000bab10c
        version = 5000
        txg = 105137531
        guid_sum = 4388488694021597985
        timestamp = 1413202044 UTC = Mon Oct 13 14:07:24 2014
Uberblock[124]
        magic = 0000000000bab10c
        version = 5000
        txg = 105137532
        guid_sum = 4388488694021597985
        timestamp = 1413202051 UTC = Mon Oct 13 14:07:31 2014
Uberblock[125]
        magic = 0000000000bab10c
        version = 5000
        txg = 105137533
        guid_sum = 4388488694021597985
        timestamp = 1413202059 UTC = Mon Oct 13 14:07:39 2014
Uberblock[126]
        magic = 0000000000bab10c
        version = 5000
        txg = 105137534
        guid_sum = 4388488694021597985
        timestamp = 1413202061 UTC = Mon Oct 13 14:07:41 2014
Uberblock[127]
        magic = 0000000000bab10c
        version = 5000
        txg = 105137535
        guid_sum = 4388488694021597985
        timestamp = 1413202062 UTC = Mon Oct 13 14:07:42 2014
 
peterle schrieb:
Trotzdem sollte das nicht den Kernel killen, wenn der nicht auf genau dieser Platte liegt oder?
Zum Vergrößern anklicken....
Das ist eine philosophische Frage mit hohen Offtopic-Potential. Natürlich hast du vollkommen recht. Ein Hardwareausfall sollte den Kernel idealerweise nicht killen, eine reine Softwareoperation schon gar nicht. Nun hat es bei den BSDs allerdings eine gewisse Tradition, jede potentielle Inkonsistenz innerhalb des Kernels mit einem Aufruf in panic() zu quittieren. Die Argumentation dahingehend ist, dass man irgendwie in einen Zustand gelangt ist, welchen man niemals hätte erreichen dürfen. Da nicht nachvollziehbar ist, wieso es passierte, ist der sofortige Abbruch besser als zu riskieren, dass z.B. Müll auf die Festplatten geschrieben wird. Linuxer sehen es etwas entspannter. Dort wird erst versucht die Sache sanft zu retten, wenn das nichts bringt gibt es einen Kernel Oops und erst als letzte Option die Panic.
Das vfs.zfs.recover Tuneable schaltet allerdings eine ganze Reihe an Panics im ZFS-Code ab. Der Fehler wird zwar erkannt, aber eben nicht mit einem Aufruf in panic() kommentiert. Sofern ret das Tuneable gesetzt hat, ist die Chance daher relativ hoch, dass sich auch Illumos und Linux an dem Pool völlig verschlucken werden.
 
Das ist ja auch sinnvoll einen full-stop mit einer panic hinzulegen, bevor sonst noch was zu Bruch geht.
Aber so ein OS ist ja Work-In-Progress und mit jedem Fehler, den man sinnvoller abfangen kann, wird das Ganze immer stabiler. Insofern halte ich es für sinnvoll den Fehler mal auf einer Liste vorzustellen. Mehr als ein Geh-Sterben oder eine Merkbefreiung kann man sich ja nicht einfangen. ;)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben