Geli error=1

RobJ

Well-Known Member
Hallo,

ich versuche gerade mein verschlüsseltes Raidarray (dev/da1) zu mounten. Dabei gibt geli error=1 aus. Der Rechner war ohne Grund in den letzten Tagen heftig abgestützt.
Gibt es ein Log, indem Fehler über die letzten 7-10 Tage gelistet werden?
Was kann ich für das Raid tun?

Grüße
RobJ
 
Diese Situation kommt mir bekannt vor. In meinem Falle hat ein fsck die mount-Probleme behoben.
Über ein Log weiss ich leider nichts.
 
Hallo,

Diese Situation kommt mir bekannt vor. In meinem Falle hat ein fsck die mount-Probleme behoben.
Über ein Log weiss ich leider nichts.

ich wollte Dir gerade zunächst antworten, daß ich mich wohl falsch ausgedrückt haben muß. Schließlich kann ich ja nichts mit fsck_ufs reparieren lassen, wenn "geli attach /dev/da0" bereits mit Fehlermeldung abbricht, und demnach da0.eli nicht existiert. Ich hab also vorher nachgesehen, und mit Überraschung festgestellt, da0 /dev/da0.eli schon/noch existierte. Heißt das etwa, die *.eli Devices bleiben bei einem Systemcrash oder -reset bestehen? Dann wäre die Verschlüsselung ja überwunden?!

Grüße
RobJ
 
Vielleicht war dein attach erfolgreich und die Fehlermeldung war bloß eine Warnung, dass etwas nicht in Ordung scheint.
 
Hallo,

Vielleicht war dein attach erfolgreich und die Fehlermeldung war bloß eine Warnung, dass etwas nicht in Ordung scheint.

so sieht es auch aus:

Code:
lisa# fsck_ufs /dev/da0.eli
** /dev/da0.eli
** Last Mounted on /mnt/disk_array_1
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=185967040 (4 should be 0)
CORRECT? [yn]

*.eli zu prüfen ist doch richtig, oder?
Was soll ich machen?

Grüße
RobJ
 
Im Zweifelsfall musst du sowieso ein Backup image machen. Aber das fsck muss sein.
 
Hallo,

>...
Der Rechner war ohne Grund in den letzten Tagen heftig abgestützt.
Gibt es ein Log, indem Fehler über die letzten 7-10 Tage gelistet werden?

jetzt ist der Absturz erneut vorgekommen.
Ich wollte ein Backup des verschlüsselten Array auf ein anderes vornehmen, bevor ich ein fsck_ufs /dev/da0.eli vornehme.
Jetzt erscheint folgende Fehlermeldung:
"swap_pager: indefinite swap buffer" mit ein paar Zahlen.
Selbst STRG+Alt+Entf läßt den Rechner nicht neu starten.

Liegt das wirklich an der Swap-Partition, oder kann es einen "Pufferüberlauf" geben, weil meine Raids nicht richtig laufen, und den Cache zu müllen?

Grüße
RobJ


Edit:

Ich habe in /var/log/messages folgendes gefunden. Kann mir das jemand bitte deuten?

May 7 22:48:21 lisa kernel: ahc0:A:4: no active SCB for reconnecting target - issuing BUS DEVICE RESET
May 7 22:48:21 lisa kernel: SAVED_SCSIID == 0x47, SAVED_LUN == 0x0, ARG_1 == 0xff ACCUM = 0x80
May 7 22:48:21 lisa kernel: SEQ_FLAGS == 0xc0, SCBPTR == 0x0, BTT == 0xff, SINDEX == 0x31
May 7 22:48:21 lisa kernel: SCSIID == 0x0, SCB_SCSIID == 0x67, SCB_LUN == 0x0, SCB_TAG == 0xff, SCB_CONTROL == 0x80
May 7 22:48:21 lisa kernel: SCSIBUSL == 0x2, SCSISIGI == 0xc6
May 7 22:48:21 lisa kernel: SXFRCTL0 == 0x88
May 7 22:48:21 lisa kernel: SEQCTL == 0x10
May 7 22:48:21 lisa kernel: >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<<
May 7 22:48:21 lisa kernel: ahc0: Dumping Card State in Status phase, at SEQADDR 0x1a7
May 7 22:48:21 lisa kernel: Card was paused
May 7 22:48:21 lisa kernel: ACCUM = 0x80, SINDEX = 0x31, DINDEX = 0x65, ARG_2 = 0x0
May 7 22:48:21 lisa kernel: HCNT = 0x0 SCBPTR = 0x0
May 7 22:48:21 lisa kernel: SCSIPHASE[0x20]:(STATUS_PHASE) SCSISIGI[0xc6]:(REQI|BSYI|IOI|CDI)
May 7 22:48:21 lisa kernel: ERROR[0x0] SCSIBUSL[0x2] LASTPHASE[0xc0]:(IOI|CDI)
May 7 22:48:21 lisa kernel: SCSISEQ[0x12]:(ENAUTOATNP|ENRSELI) SBLKCTL[0xa]:(SELWIDE|SELBUSB)
May 7 22:48:21 lisa kernel: SCSIRATE[0x0] SEQCTL[0x10]:(FASTMODE) SEQ_FLAGS[0xc0]:(NO_CDB_SENT|NOT_IDENTIFIED)
May 7 22:48:21 lisa kernel: SSTAT0[0x2]:(SPIORDY) SSTAT1[0x11]:(REQINIT|PHASEMIS)
May 7 22:48:21 lisa kernel: SSTAT2[0x0] SSTAT3[0x0] SIMODE0[0x8]:(ENSWRAP) SIMODE1[0xac]:(ENSCSIPERR|ENBUSFREE|ENSCSIRST|ENSELTIM
May 7 22:48:21 lisa kernel: SXFRCTL0[0x88]:(SPIOEN|DFON) DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL)
May 7 22:48:21 lisa kernel: STACK: 0x140 0x0 0x164 0x10a
May 7 22:48:21 lisa kernel: SCB count = 20
May 7 22:48:21 lisa kernel: Kernel NEXTQSCB = 8
May 7 22:48:21 lisa kernel: Card NEXTQSCB = 8
May 7 22:48:21 lisa kernel: QINFIFO entries:
May 7 22:48:21 lisa kernel: Waiting Queue entries:
May 7 22:48:21 lisa kernel: Disconnected Queue entries:
May 7 22:48:21 lisa kernel: QOUTFIFO entries:
May 7 22:48:21 lisa kernel: Sequencer Free SCB List: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
May 7 22:48:21 lisa kernel: Sequencer SCB Info:
May 7 22:48:21 lisa kernel: 0 SCB_CONTROL[0x80]:(TARGET_SCB) SCB_SCSIID[0x67] SCB_LUN[0x0]
May 7 22:48:21 lisa kernel: SCB_TAG[0xff]
May 7 22:48:21 lisa kernel: 1 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
May 7 22:48:21 lisa kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
May 7 22:48:21 lisa kernel: 2 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
May 7 22:48:21 lisa kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
May 7 22:48:21 lisa kernel: 3 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
May 7 22:48:21 lisa kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
May 7 22:48:21 lisa kernel: 4 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
 
Zuletzt bearbeitet:
Sorry, aber vorm attach immer erst ein fsck. Klingt logisch, ist auch so. ;-)
Und bei Deinem SCSI-Bus harkt es grad, den wuerde ich vorerst als Problem Nr.1 behandeln. D.h. alles durchchecken, also erst Raid, dann fsck und dann attach.
Pruegelt mich, wenn ich mich irre.
 
Hallo,

Sorry, aber vorm attach immer erst ein fsck. Klingt logisch, ist auch so. ;-)
Und bei Deinem SCSI-Bus harkt es grad, den wuerde ich vorerst als Problem Nr.1 behandeln. >...

ich verstehe die Welt nicht mehr.
Ich habe das zu letzt angefügte SCSI Gerät in der Hoffnung wieder entfernt, die SCSI Kette wieder zu besänftigen. Ich vermute, daß das U160 Kabel des letzten Gerätes nicht die erforderliche Qualität aufweist.
Der zweite Schritt wäre also fsck, doch bis dahin komme ich nicht mehr. FreeBSD stürzt mit Kernel Trap 12 ab. Hab den genauen Wortlaut nicht vorliegen, doch es ging um den Swapbereich. Jener sollte mit Geli und der im System integrierten VPN1401 hardwareseitig verschlüsselt werden.
Seitdem ich die Kryptokarte drin habe, gibt es Schwierigkeiten mit dem kompletten System. In der Bootmeldung taucht Geli mit der Meldung "AES 256 Hardware" auf.
Sind Probleme mit der Karte bekannt?
Das System bootet in einer Schleife durchgehend. Wie kriege ich das System wieder flott? Kann ich da etwas im Single-User-Mode machen, womöglich den Swapbereich überprüfen / wieder herstellen?

Grüße
RobJ
 
Zurück
Oben