ZFS auf GELI-Device: Kernel Panic (FreeBSD 8.2)

M

Morfio

Well-Known Member
Hallo zusammen,

ich habe einen kleinen Heimserver mit FreeBSD 8.2. Darin verbaut ist eine RAID-Karte von HighPoint (RocketRaid 1740), an der drei Platten zu einem RAID5 verbunden sind.

Das Device da0p6 ist mit GELI verschlüsselt. Darauf befindet sich ein ZFS-Pool mit etlichen Volumes.

Der Server war heute auf einmal nicht mehr erreichbar. Als ich nach Hause kam, hatte er wohl einen Kernel Panic (keine Ahnung, ob es wirklich einer war, der Monitor ging nicht mehr an).

Reset, FreeBSD bootet durch. Das GELI-Device läßt sich einhängen, startet man aber jetzt ZFS, verabschiedet sich der Server wieder mit einem Kernel-Panic (s. Anhang).

Laut dem RAID-Controller sind alle Platten sowie das Array in Ordnung:

Code: 
HighPoint CLI>query devices
ID      Capacity    MaxFree     Flag    Status    ModelNumber
-------------------------------------------------------------------------------
1/1     2000.31     0           RAID    NORMAL    SAMSUNG HD204UI
1/2     2000.31     0           RAID    NORMAL    SAMSUNG HD204UI
1/3     2000.31     0           RAID    NORMAL    SAMSUNG HD204UI

Code: 
HighPoint CLI>query arrays
ID   Capacity(GB) Type        Status    Block   Sector  Cache   Name            
-------------------------------------------------------------------------------
1    4000.63      RAID5       NORMAL    64k     512B    WB      RAID_5_0

Sobald ich was mit "zpool" aufrufe, raucht die Maschine ab.

Was könnte das sein und wie bekomme ich das wieder in den Griff? Kann man ein scrub ohne eingehängte Pools machen?

Viele Grüße, Morfio
 

Anhänge

  • Bild 1.webp
    Bild 1.webp
    74,4 KB · Aufrufe: 354
Er stürzt im Moment des Imports bzw. Mounts ab? Das ist ein Hinweis auf einen zerdepperten Pool. Sowas kann viele Ursachen haben, meist ist aber eine Form von Hardwareversagen schuld. Die Liste der Möglichkeiten ist natürlich lang, es beginnt bei defekten RAM, geht über die Kabel zur Festplatte und so weiter. Mein einziger bisher verlorener Pool geht so auf das Konto eines Bugs in age(4)... Aber egal, das hilft dir nun nichts mehr.

Vorweg hoffe ich, dass du ein Backup hast. Nun muss man wissen, dass das ZFS v15 von FreeBSD 8.2 kaum Möglichkeiten hat an sich korrigierbare Fehler auszubügeln. Ist dort zum Beispiel die ZIL defekt oder sind bereits in den Pool geschriebene Transaktionsgruppen beschädigt, ist Ende. Helfen kann man sich nur mit manuellen Eingriffen mit zdb(1). Nun hat damals aber noch Sun in späteren Versionen Automatismen implementiert. Ich würde als erste Aktion die FreeBSD 9.0-BETA1 runterladen, die Installations-CDs sind ja nun auch echte Live-CDs. Dort versuchst du stumpf einen Import. Geht es schief, stürzt er wieder ab und du hast nichts verloren. Greift die Autokorrektur des ZFSv28, wird der Pool importiert. Anschließend kannst du ein Scrub durchführen, den Pool dann sauber exportieren und ins installierte 8.2 wieder importieren. Reißen alle Stricke, kannst du das Ganze auch noch einmal mit einer Live-CD eines der OpenSolaris-Abkömmlinge ausprobieren. Die sind u.U. noch ein wenig robuster.
 
Hallo,

danke für die Antwort. Ich werde das gleich mal ausprobieren. Glücklicherweise bin ich recht paranoid und jede Nacht läuft glücklicherweise ein Backup auf externe verschlüsselte Platten (:. In so fern wäre der Schaden schon da, aber nicht so groß.

Vielen Dank, Morfio
 
Nein. Die BETA hat einfach noch den Debugkrempel drin, daher landest du im Debugger sobald die Panic auftritt. Wenn ich mal raten darf, hat dir etwas die ZIL soweit zerdeppert, dass er sie nicht mehr lesen kann. Einfach gesagt bedeutet es: "If the ZFS pool version is under 19, and you do not have a mirrored log device, you're screwed." Du kannst noch versuchen im Loader "vfs.zfs.zil_disable=1" zu setzen, aber wahrscheinlich wird es nicht helfen. Dann bleibt noch rumgefrickel mit dem zdb, aber mal ehrlich... Wenn du ein Backup hast, würde ich es zurückspielen und die Zeit lieber in Überlegungen investieren was den Pool zerlegt haben könnte.
 
Morfio schrieb:
Hallo,

danke für die Antwort. Ich werde das gleich mal ausprobieren. Glücklicherweise bin ich recht paranoid und jede Nacht läuft glücklicherweise ein Backup auf externe verschlüsselte Platten (:. In so fern wäre der Schaden schon da, aber nicht so groß.

Vielen Dank, Morfio
Zum Vergrößern anklicken....

Moin..... Um das nachzuvollziehen... die Forensik wäre in dem Fall wichtig.

Setz mal bite folgendes Kommando ab...

Code: 
zdb -eu >> test.txt

Code: 
zdb -eC poolname

Konfig auslesen...
Dann das ganze bitte hier posten.

Falls irgendwo ein Coredump rum liegt wäre das auch nicht unschön...

Eins noch... am besten wäre es wenn Du den Pool in einem OpenSolaris b134 oder eineme Solaris 10u9 importieren könntest, dann könnte man mit mdb rangehen.
 
Zuletzt bearbeitet:
Bei zdb -eu kommt die Hilfe, da fehlt wohl noch was.

Code: 
[root@homer ~]# zdb -eC       
server
    version=14
    name='server'
    state=0
    txg=4
    pool_guid=12986859583500627213
    hostid=1213244773
    hostname='homer4.dynsoft.ds'
    vdev_tree
        type='root'
        id=0
        guid=12986859583500627213
        children[0]
                type='disk'
                id=0
                guid=4131926971436614226
                path='/dev/da0p6.eli'
                whole_disk=0
                metaslab_array=23
                metaslab_shift=35
                ashift=12
                asize=3913582903296
                is_log=0

Core-Dump kann er leider nicht schreiben.
 
Morfio schrieb:
Bei zdb -eu kommt die Hilfe, da fehlt wohl noch was.

Code: 
[root@homer ~]# zdb -eC       
server
    version=14
    name='server'
    state=0
    txg=4
    pool_guid=12986859583500627213
    hostid=1213244773
    hostname='homer4.dynsoft.ds'
    vdev_tree
        type='root'
        id=0
        guid=12986859583500627213
        children[0]
                type='disk'
                id=0
                guid=4131926971436614226
                path='/dev/da0p6.eli'
                whole_disk=0
                metaslab_array=23
                metaslab_shift=35
                ashift=12
                asize=3913582903296
                is_log=0

Core-Dump kann er leider nicht schreiben.
Zum Vergrößern anklicken....

Kannst DU den Pool über id antatschen?
Also einfach der Versuch eines Imports über
Code: 
zpool import 12986859583500627213

falls erfolgreich ein zpool export -f durch ziehen und danach ein zpool import




Wenn nein... dann mal bitte..... den Uberblock auslesen...

Ach ja nur zur Anmerkung...

die Anzahl der Buchstaben also z.B. u wenn mehrfach angegeben sagt dem Debugger wie geschwätzig/verbose Er sein soll.

Code: 
zdb -uuu meinpool

Mein anderer Vorschlag wäre mal... boote die Büchse doch mal von einer Opensolaris Live CD, wie es Yamagi schon vorgeschlagen hat...

dann versuch den Pool dort direkt zu importieren... Wir können zwar lange mit zdb rumspielen, da findet man auch viel raus. Ob man es ganz gefixt bekommt.. ist aber fraglich.

Aber das wäre glaub ich der erst mal schmerzfreieste Ansatz, sonst könnten wir hier die ganze Nacht rumspielen, vielleicht kriegen wir es sogar gefixt, aber es kann dauern, ich spekulier mal das er sich an irgend einer TGX verschluckt hat.

Außerdem dürfte da der ZDB aktueller sein..

Was man noch machen könnte...

wäre folgendes
Code: 
zdb -ebbcsL
 
Zuletzt bearbeitet:
falls erfolgreich ein zpool export -f durch ziehen und danach ein zpool import
Zum Vergrößern anklicken....

Funktioniert über die ID leider auch nicht.

Mit Solaris würde ich es versuchen, allerdings liegt der zpool ja auf einem GELI-Device, da kommt ich vermutlich mit Solaris nicht ran, oder?
 
Morfio schrieb:
Funktioniert über die ID leider auch nicht.

Mit Solaris würde ich es versuchen, allerdings liegt der zpool ja auf einem GELI-Device, da kommt ich vermutlich mit Solaris nicht ran, oder?
Zum Vergrößern anklicken....

Ich würde es in jedem fall mal probieren, was GELI angeht, ich kann es nicht sagen, aber es wäre definitiv einen Versuch wert.
 
[root@homer ~]# zdb -e server
Uberblock

magic = 0000000000bab10c
version = 15
txg = 4170426
guid_sum = 17118786554937241439
timestamp = 1312923666 UTC = Tue Aug 9 23:01:06 2011

Dataset mos [META], ID 0, cr_txg 4, 46.8M, 193 objects

Metaslabs:
vdev offset spacemap free
---------- ------------------- --------------- -------------
vdev 0 offset 0 spacemap 26 free 951M
vdev 1 offset 800000000 spacemap 34 free 2.25G
vdev 2 offset 1000000000 spacemap 50 free 76.0M
vdev 3 offset 1800000000 spacemap 54 free 163M
vdev 4 offset 2000000000 spacemap 70 free 1.87G
vdev 5 offset 2800000000 spacemap 75 free 3.65G
vdev 6 offset 3000000000 spacemap 43 free 1.07G
vdev 7 offset 3800000000 spacemap 45 free 772M
vdev 8 offset 4000000000 spacemap 113 free 48.6M
vdev 9 offset 4800000000 spacemap 117 free 1.87G
vdev 10 offset 5000000000 spacemap 83 free 10.6G
vdev 11 offset 5800000000 spacemap 86 free 9.6G
vdev 12 offset 6000000000 spacemap 128 free 10.1G
vdev 13 offset 6800000000 spacemap 135 free 43.1M
vdev 14 offset 7000000000 spacemap 139 free 552M
vdev 15 offset 7800000000 spacemap 142 free 825M
vdev 16 offset 8000000000 spacemap 145 free 647M
vdev 17 offset 8800000000 spacemap 151 free 7.69G
vdev 18 offset 9000000000 spacemap 154 free 20.4G
vdev 19 offset 9800000000 spacemap 159 free 25.1G
vdev 20 offset a000000000 spacemap 160 free 12.5G
vdev 21 offset a800000000 spacemap 161 free 22.9G
vdev 22 offset b000000000 spacemap 25 free 92.4M
vdev 23 offset b800000000 spacemap 35 free 898M
vdev 24 offset c000000000 spacemap 51 free 1.75G
vdev 25 offset c800000000 spacemap 55 free 1.94G
vdev 26 offset d000000000 spacemap 71 free 1.94G
vdev 27 offset d800000000 spacemap 76 free 5.14G
vdev 28 offset e000000000 spacemap 42 free 585M
vdev 29 offset e800000000 spacemap 44 free 749M
vdev 30 offset f000000000 spacemap 114 free 5.40G
vdev 31 offset f800000000 spacemap 116 free 5.65G
vdev 32 offset 10000000000 spacemap 84 free 25.8G
vdev 33 offset 10800000000 spacemap 87 free 6.65G
vdev 34 offset 11000000000 spacemap 147 free 4.76G
vdev 35 offset 11800000000 spacemap 136 free 186M
vdev 36 offset 12000000000 spacemap 140 free 552M
vdev 37 offset 12800000000 spacemap 141 free 557M
vdev 38 offset 13000000000 spacemap 146 free 830M
vdev 39 offset 13800000000 spacemap 150 free 8.16G
vdev 40 offset 14000000000 spacemap 156 free 13.1G
vdev 41 offset 14800000000 spacemap 157 free 30.5G
vdev 42 offset 15000000000 spacemap 163 free 19.0G
vdev 43 offset 15800000000 spacemap 164 free 7.77G
vdev 44 offset 16000000000 spacemap 24 free 72.9M
vdev 45 offset 16800000000 spacemap 49 free 228M
vdev 46 offset 17000000000 spacemap 52 free 1.87G
vdev 47 offset 17800000000 spacemap 57 free 4.36G
vdev 48 offset 18000000000 spacemap 72 free 1.31G
vdev 49 offset 18800000000 spacemap 166 free 28.3G
vdev 50 offset 19000000000 spacemap 173 free 32.0G
vdev 51 offset 19800000000 spacemap 46 free 416M
vdev 52 offset 1a000000000 spacemap 174 free 25.1G
vdev 53 offset 1a800000000 spacemap 124 free 12.2G
vdev 54 offset 1b000000000 spacemap 175 free 18.1G
vdev 55 offset 1b800000000 spacemap 125 free 5.36G
vdev 56 offset 1c000000000 spacemap 148 free 5.05G
vdev 57 offset 1c800000000 spacemap 137 free 454M
vdev 58 offset 1d000000000 spacemap 176 free 14.3G
vdev 59 offset 1d800000000 spacemap 143 free 300M
vdev 60 offset 1e000000000 spacemap 183 free 23.8G
vdev 61 offset 1e800000000 spacemap 152 free 1.19G
vdev 62 offset 1f000000000 spacemap 184 free 25.5G
vdev 63 offset 1f800000000 spacemap 158 free 16.0G
vdev 64 offset 20000000000 spacemap 185 free 32.0G
vdev 65 offset 20800000000 spacemap 186 free 22.7G
vdev 66 offset 21000000000 spacemap 33 free 1.84G
vdev 67 offset 21800000000 spacemap 187 free 11.5G
vdev 68 offset 22000000000 spacemap 53 free 163M
vdev 69 offset 22800000000 spacemap 188 free 24.0G
vdev 70 offset 23000000000 spacemap 73 free 649M
vdev 71 offset 23800000000 spacemap 165 free 28.7G
vdev 72 offset 24000000000 spacemap 189 free 22.6G
vdev 73 offset 24800000000 spacemap 112 free 6.92G
vdev 74 offset 25000000000 spacemap 190 free 32.0G
vdev 75 offset 25800000000 spacemap 82 free 3.30G
vdev 76 offset 26000000000 spacemap 153 free 10.3G
vdev 77 offset 26800000000 spacemap 126 free 25.9G
vdev 78 offset 27000000000 spacemap 149 free 1002M
vdev 79 offset 27800000000 spacemap 138 free 570M
vdev 80 offset 28000000000 spacemap 155 free 17.0G
vdev 81 offset 28800000000 spacemap 144 free 990M
vdev 82 offset 29000000000 spacemap 191 free 31.9G
vdev 83 offset 29800000000 spacemap 192 free 31.9G
vdev 84 offset 2a000000000 spacemap 193 free 7.43G
vdev 85 offset 2a800000000 spacemap 162 free 1.75G
vdev 86 offset 2b000000000 spacemap 0 free 32G
vdev 87 offset 2b800000000 spacemap 0 free 32G
vdev 88 offset 2c000000000 spacemap 48 free 155M
vdev 89 offset 2c800000000 spacemap 0 free 32G
vdev 90 offset 2d000000000 spacemap 56 free 3.51G
vdev 91 offset 2d800000000 spacemap 0 free 32G
vdev 92 offset 2e000000000 spacemap 74 free 74.9M
vdev 93 offset 2e800000000 spacemap 0 free 32G
vdev 94 offset 2f000000000 spacemap 0 free 32G
vdev 95 offset 2f800000000 spacemap 115 free 1.27G
vdev 96 offset 30000000000 spacemap 0 free 32G
vdev 97 offset 30800000000 spacemap 85 free 41.4M
vdev 98 offset 31000000000 spacemap 0 free 32G
vdev 99 offset 31800000000 spacemap 127 free 30.0G
vdev 100 offset 32000000000 spacemap 0 free 32G
vdev 101 offset 32800000000 spacemap 0 free 32G
vdev 102 offset 33000000000 spacemap 0 free 32G
vdev 103 offset 33800000000 spacemap 0 free 32G
vdev 104 offset 34000000000 spacemap 0 free 32G
vdev 105 offset 34800000000 spacemap 0 free 32G
vdev 106 offset 35000000000 spacemap 0 free 32G
vdev 107 offset 35800000000 spacemap 0 free 32G
vdev 108 offset 36000000000 spacemap 0 free 32G
vdev 109 offset 36800000000 spacemap 0 free 32G
vdev 110 offset 37000000000 spacemap 0 free 32G
vdev 111 offset 37800000000 spacemap 0 free 32G
vdev 112 offset 38000000000 spacemap 0 free 32G

Dataset server/media [ZPL], ID 30, cr_txg 12, 1.32T, 10775 objects
Dataset server/stuff [ZPL], ID 109, cr_txg 981871, 87.4G, 15281 objects
Dataset server/iscsi [ZPL], ID 132, cr_txg 2348304, 600G, 4 objects
Dataset server/databases [ZPL], ID 170, cr_txg 3805256, 128M, 4099 objects
Dataset server/backup [ZPL], ID 79, cr_txg 981856, 8.91G, 257197 objects
Dataset server/home [ZPL], ID 121, cr_txg 1005091, 26.8G, 20015 objects
Dataset server/documents [ZPL], ID 97, cr_txg 981867, 3.04G, 4997 objects
Dataset server/jails/devel [ZPL], ID 67, cr_txg 518565, 1.89G, 181763 objects
Dataset server/jails/marge [ZPL], ID 61, cr_txg 518538, 4.44G, 255330 objects
Dataset server/jails/bolso [ZPL], ID 180, cr_txg 3879493, 201M, 10720 objects
Dataset server/jails [ZPL], ID 39, cr_txg 89176, 112K, 6 objects
Dataset server/development [ZPL], ID 91, cr_txg 981863, 77.2M, 713 objects
Dataset server/software [ZPL], ID 103, cr_txg 981869, 22.7G, 1731 objects
Dataset server [ZPL], ID 16, cr_txg 1, 168K, 13 objects
Zum Vergrößern anklicken....

Muss der Pool vllt. eingehängt sein?

[root@homer ~]# zdb -uuu server
zdb: can't open server: No such file or directory
Zum Vergrößern anklicken....
 
Hast Du mal in diesen Thread reingekuckt?

Abgesehen davon.... ist der Pool über das komplete Raid gelegt?
Kein Mirror?


Also zieh in jedem Fall jetzt mal die OpenSolaris CD damit man wenigstens mal einen Import versuchen kann und eine aktuellere zdb Version hat. Es ist definitiv einen Versuch wert.
 
solarix schrieb:
Hast Du mal in diesen Thread reingekuckt?
Zum Vergrößern anklicken....

Noch nicht, ich probiere das mal flott aus.

solarix schrieb:
Abgesehen davon.... ist der Pool über das komplete Raid gelegt?
Kein Mirror?
Zum Vergrößern anklicken....

Die drei Platten sind im Hardware-RAID-5, darauf sind dann die Partitionen, auf einem liegt GELI mit dem ZFS darauf.

solarix schrieb:
Also zieh in jedem Fall jetzt mal die OpenSolaris CD damit man wenigstens mal einen Import versuchen kann und eine aktuellere zdb Version hat. Es ist definitiv einen Versuch wert.
Zum Vergrößern anklicken....

Es gibt leider kein geom_mirror unter OpenSolaris, damit kann ich die Platte nicht entschlüsseln und komme so auch nicht an das ZFS.
 
Hmm, um den unten angeregten Fix hinzubekommen, fehlen mir die Kapazitäten. Das ZFS-Ding ist um die 4GB groß.

Ich habe bereits neue Hardware bestellt, ich hoffe, dass das Backup vollständig ist (:
 
Morfio schrieb:
Es gibt leider kein geom_mirror unter OpenSolaris, damit kann ich die Platte nicht entschlüsseln und komme so auch nicht an das ZFS.
Zum Vergrößern anklicken....

Wenn Opensolaris geom_mirror hätte, würde es dir auch nicht weiterhelfen. ;)

Versuche doch mit dem geom_geli Modul die nötigen Dateien/Geräte einzuhängen (geht ja anscheinend), und dann mittels
Code: 
dd if=/dev/xx.eli of=/mnt/elidevicedump
(xx=da0p6) diese auf eine andere Platte/Stick/Partition/Dateisystem zu schreiben. Dann versuch den zpool unter Opensolaris mit den Dateien/Devices einzuhängen.
 
Nukama schrieb:
Wenn Opensolaris geom_mirror hätte, würde es dir auch nicht weiterhelfen. ;)

Versuche doch mit dem geom_geli Modul die nötigen Dateien/Geräte einzuhängen (geht ja anscheinend), und dann mittels
Code: 
dd if=/dev/xx.eli of=/mnt/elidevicedump
(xx=da0p6) diese auf eine andere Platte/Stick/Partition/Dateisystem zu schreiben. Dann versuch den zpool unter Opensolaris mit den Dateien/Devices einzuhängen.
Zum Vergrößern anklicken....

Würde ich ja tun, aber es handelt sich um vier Terrabytes, da habe ich keine Kapazitäten für.
 
Ich würd den Stress sein lassen und das Backup auf neu formatierte Platten zurückspielen... Du sagtest ja, dass du jede Nacht eins machst.
 
Ja, werde ich auch machen. Neuer Server ist bestellt, da ich beim alten einen Hitzeschaden vermute. Ich werde allerdings noch probieren, den Controller und die Festplatten in einen anderen Rechner einzubauen.
 
Ich glaube, die Sache hat sich sowieso erledigt, denn jetzt kommen Kernel Panics bereits beim Booten der Maschine. Da scheint Hardware über den Bach gegangen zu sein.
 
Noch mal für das Archiv, falls hier jemand auf der Suche nach einer Lösung reinschauen sollte: FreeBSDs ZFSv28 hat die undokumentierte Option "-F" für das "zpool import" Kommando. Damit wird der Pool automatisch auf eine ältere Transaktionsgruppe zurückgerollt. Das bedeutet einen Datenverlust - die letzten Änderungen gehen verloren - kann aber unter Umständen einen defekten Pool wieder zum Leben erwecken.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben