This is the old XigmaNAS forum in read only mode,
it will taken offline by the end of march 2021!



I like to aks Users and Admins to rewrite/take over important post from here into the new fresh main forum!
Its not possible for us to export from here and import it to the main forum!

Problem: "the primary GPT table is corrupt or invalid"

German community

Moderators: b0ssman, apollo567, Princo, crowi

Forum rules
Set-Up GuideFAQsForum Rules
Post Reply
raaalf
experienced User
experienced User
Posts: 80
Joined: 17 Dec 2014 12:45
Status: Offline

Problem: "the primary GPT table is corrupt or invalid"

Post by raaalf »

Hallo zusammen,

es ist mir peinlich, aber ich habe schon wieder ein Problem...

Im Log-File meines N4F-Systems ist folgender, unschöner Eintrag zu finden:

GEOM_MIRROR: Device mirror/Festplatte12 launched (2/2).
GEOM: mirror/Festplatte12: the primary GPT table is corrupt or invalid.
GEOM: mirror/Festplatte12: using the secondary instead -- recovery strongly advised.

Ich habe schon im N4F- wie auch FreeBSD-Forum nach der Lösung dieses Problems gesucht. Eine Empfehlung war, einen "full fsck" (file system consistency check and interactive repair) laufen zu lassen. Ich denke, dies geht nur über die Kommandozeile? Denn die fsck-Funktion unter "Festplatten|Einhängepunkt|Fsck" zeigt keine Fehlermeldungen.

Ein einfaches Drauflosprobieren ist mir zu heikel, da sich bereits ca. 300 GByte an Daten auf dem NAS befinden. Die Daten sind zwar gesichert, aber der Zeitaufwand des Kopierens per 100 MBit/s-LAN...
Weiß jemand von euch wie dieses Problem zustande kommt und korrekt behoben werden kann?

Was mir noch aufgefallen ist, ist dieser Eintrag im Log-File ("Flags: DIRTY"):

Providers:
1. Name: mirror/Festplatte12
Mediasize: 1000204885504 (931G)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r1w1e3
Consumers:
1. Name: ada2
Mediasize: 1000204886016 (931G)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r1w1e1
State: ACTIVE
Priority: 1
Flags: DIRTY
GenID: 0
SyncID: 1
ID: 2763737225
2. Name: ada1
Mediasize: 1000204886016 (931G)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r1w1e1
State: ACTIVE
Priority: 0
Flags: DIRTY
GenID: 0
SyncID: 1
ID: 1140520261

Ist es korrekt, dass das Dirty-Flag nur aussagt, das

"Don't worry if you see DIRTY on the Flags line, as it simply indicates that the system has written new data to the disk but hasn't mirrored it yet. If you were to wait a few seconds on a quiet disk, you would see the Flags line change to NONE." [1]

Aktuell werden Daten in erhelbichem Umfang (ca. 100 GByte) auf das NAS geschoben.

[1] http://www.onlamp.com/pub/a/bsd/2005/11 ... tml?page=2

Jetzt bleibt mir nur, euch einen guten Rutsch ins Jahr 2015 zu wünschen und immer ein Log-File eures NAS ohne Error-Einträge. ;-)

Ralf
NAS-PRODUKTIV: HP ProLiant MicroServer N54L | MicroServer Remote Access Card | 16 GByte ECC DRAM (Kingston KVR1333D3E9SK2_16G) | 3 x 3 TByte WD RED (30EFRX) | 9.2.0.1 Shigawire (Revision 972), x64 Embedded

NAS-BACKUP: Wie NAS-PRODUKTIV aber mit 8 GByte ECC DRAM

NAS-IMAGES: Wie NAS-PRODUKTIV aber mit 4 x 3 TByte WD RED (30EFRX) und 10.2.0.2 - Prester (revision 1868)

Joerg
experienced User
experienced User
Posts: 134
Joined: 06 Dec 2014 17:53
Location: Deutschland, Peine
Status: Offline

Re: Problem: "the primary GPT table is corrupt or invalid"

Post by Joerg »

Was sagen deine Smart Daten der Platten?, wie Formatiert?
NasBox1: AsRock B75 Pro3, Intel Celeron G1610, 8GB Kingston KHX1600C10D3/8GX, Platinum 2GB usb2 stick. 3x 3TB WD Red, 3x 4TB WD Red, 9.2.0.1.972 X64 embedded

NasBox2: AsRock B75 Pro3, Intel Celeron G1610, 8GB Kingston KHX1600C10D3/8GX, Sandisk Extreme 32gb usb3 Stick. 1x 2TB WD Red, 1x 4TB WD Red, 9.3.0.2.1283 X64 embedded

raaalf
experienced User
experienced User
Posts: 80
Joined: 17 Dec 2014 12:45
Status: Offline

Re: Problem: "the primary GPT table is corrupt or invalid"

Post by raaalf »

Servus Jörg,
Joerg wrote:Was sagen deine Smart Daten der Platten?, wie Formatiert?
die SMART-Werte der Festplatten sind laut Log-File und GUI in Ordnung. Die Festplatten sind neu und erst wenige Tage in Betrieb und unter Linux mit badblocks -wsv auf defekte Sektoren gechecked.

Beide Festplatten sind in einem Software-RAID-1 zusammengefasst, das wiederum UFS formatiert ist.

Das Tool um Probleme mit GP-Tabellen unter FreeBSD etc. zu beheben ist ja Gpart. Kann mit einem GPart-Befehl das Problem gelöst werden? Theoretisch müsste die GPart-Option recover oder restore zielführend sein? Wie gesagt, ich möchte nicht einfach ´drauflos probieren, auch wenn es ein Testsystem ist.

Weisst Du, ob mit GPart auch ein MBR angelegt werden kann ohne die GP-Tabelle zu beeinträchtigen? Ich habe ja das Problem [1], dass das BIOS des für das N4F-Systems verwendeten Motherboards einen MBR benötigt, andernfalls nach dem Scan der Festplatten hängenbleibt. Ich frage für den Fall, dass bei den zur Problembehebung nötigen Schritten und Befehlen - welche auch immer die richtigen sein mögen - der MBR zerstört werden sollte.

[1] viewtopic.php?f=29&t=7899

Grüsse

Ralf
NAS-PRODUKTIV: HP ProLiant MicroServer N54L | MicroServer Remote Access Card | 16 GByte ECC DRAM (Kingston KVR1333D3E9SK2_16G) | 3 x 3 TByte WD RED (30EFRX) | 9.2.0.1 Shigawire (Revision 972), x64 Embedded

NAS-BACKUP: Wie NAS-PRODUKTIV aber mit 8 GByte ECC DRAM

NAS-IMAGES: Wie NAS-PRODUKTIV aber mit 4 x 3 TByte WD RED (30EFRX) und 10.2.0.2 - Prester (revision 1868)

Joerg
experienced User
experienced User
Posts: 134
Joined: 06 Dec 2014 17:53
Location: Deutschland, Peine
Status: Offline

Re: Problem: "the primary GPT table is corrupt or invalid"

Post by Joerg »

Wenn ich das richtig sehe, hast du 2 1tb platten.
das gpt protocoll sollte man allerdings erst ab 2tb aufwärts nutzen, da zum einem die kleinen platten, auch die etwas älteren die 4k blöcke weder nutzen, noch emulieren können. Zum anderen etwas ältere systeme damit nicht zurechtkommne. Ab uefi bios, gpt nutzen mit platten ab 2tb und mehr, im bios ahci aktivieren. Das ahci kannst du für alle platten verwenden, unabhängig der größe.

Es kann, muß nicht, in einigen kombies zu problemen kommen, das mußt du, wie ich derzeit auch, testen ;)
NasBox1: AsRock B75 Pro3, Intel Celeron G1610, 8GB Kingston KHX1600C10D3/8GX, Platinum 2GB usb2 stick. 3x 3TB WD Red, 3x 4TB WD Red, 9.2.0.1.972 X64 embedded

NasBox2: AsRock B75 Pro3, Intel Celeron G1610, 8GB Kingston KHX1600C10D3/8GX, Sandisk Extreme 32gb usb3 Stick. 1x 2TB WD Red, 1x 4TB WD Red, 9.3.0.2.1283 X64 embedded

raaalf
experienced User
experienced User
Posts: 80
Joined: 17 Dec 2014 12:45
Status: Offline

Re: Problem: "the primary GPT table is corrupt or invalid"

Post by raaalf »

Hallo Jörg,

ich glaube zu wissen was die Ursache das Problem ist. Bei der Einrichtung des RAID 1 ging ich wie folgt vor:

1.) Festplatten|Formatieren

- Festplatte ada1 mit Dateisystem UFS formatiert, Option "MBR (Master Boot Record) nicht löschen" war aktiv
- Festplatte ada2 mit Dateisystem UFS formatiert, Option "MBR (Master Boot Record) nicht löschen" war aktiv

2.) Festplatten|Software RAID|RAID1|

- Festplatte ada1 und ada2, RAID erstellt und initialisiert

3.) Festplatten|Formatieren

- Den RAID-1-Festplattenverbund der Festplatten ada1 und ada2 ausgewählt und mit Dateisystem UFS formatiert, Option "MBR (Master Boot Record) nicht löschen" war aktiv

Jetzt kommt der Punnkt an dem ich das System neu booten wollte, was aber nicht mehr ging, da das BIOS bei der Erkennung der Festplatten hängen blieb. Mit vom USB-Stick gebootetem GParted erstellte ich den offenbar gelöschten MBR neu - und überschrieb dabei anscheinend die primary GPT table.
Der Bootvorgang lief wieder durch. Ich dachte, der MBR und die GPT kommen sich nicht in die Quere, da an anderen Stellen auf der Festplatte abgelegt.

Das eigentliche Problem ist also, dass beim dritten Punkt, dem Formatieren des RAID-1-Festplattenverbunds, die aktivierte Option "MBR (Master Boot Record) nicht löschen" offenbar nicht zum gewünschten Ergebnis führte.

Mir ist klar, dass mein Eingriff mit GParted mehr als dilettantisch ist. Aber ich wusste mir nicht anders zu helfen. Die beiden Hitachi-Festplatten arbeiten mit "Advanced Format drive" (4K physical sectors with 512 byte emulation). Bei dem oben beschriebenen Problem spielt es keine Rolle, ob mit 4-K-Allignment partitioniert wird oder nicht. Das habe ich alles in mehreren Versuchen getestet.

Auf http://www.heise.de/ct/hotline/FAQ-Fest ... 78642.html ist zu Advanced Format Drives zu lesen:

"Was ist im Umgang mit Advanced Format Drives zu beachten?

[...] Nach außen verhalten sich die Laufwerke somit zwar wie herkömmliche Platten, dennoch gibt es ein paar Besonderheiten zu beachten, etwa bei der Partitionierung. Die Partitionen auf solchen Festplatten sollten bei einer durch acht teilbaren Sektoradresse beginnen. Anderenfalls drohen Geschwindigkeitseinbußen bei Schreibzugriffen: Um einen 4 KByte großen Datenblock zu schreiben, der über zwei physische Sektoren ragt, muss die Platte diese zunächst lesen, den betroffenen Teil der Daten ersetzen und kann sie erst dann wieder schreiben (Read-Modify-Write, RMW). Das erfordert eine zusätzliche Umdrehung der Scheiben und bremst massiv. [...]

Wenn ich jetzt mit "gpart recover" versuche die defekte GPT wiederherzustellen, dann habe ich wieder das Problem, dass das BIOS nach der Erkennung der Festplatten hängenbleibt? Hier bin ich definitiv mit meinem bißchen Latein am Ende.

Grüsse

Ralf
Joerg wrote:Wenn ich das richtig sehe, hast du 2 1tb platten.
das gpt protocoll sollte man allerdings erst ab 2tb aufwärts nutzen, da zum einem die kleinen platten, auch die etwas älteren die 4k blöcke weder nutzen, noch emulieren können. Zum anderen etwas ältere systeme damit nicht zurechtkommne. Ab uefi bios, gpt nutzen mit platten ab 2tb und mehr, im bios ahci aktivieren. Das ahci kannst du für alle platten verwenden, unabhängig der größe.

Es kann, muß nicht, in einigen kombies zu problemen kommen, das mußt du, wie ich derzeit auch, testen ;)
NAS-PRODUKTIV: HP ProLiant MicroServer N54L | MicroServer Remote Access Card | 16 GByte ECC DRAM (Kingston KVR1333D3E9SK2_16G) | 3 x 3 TByte WD RED (30EFRX) | 9.2.0.1 Shigawire (Revision 972), x64 Embedded

NAS-BACKUP: Wie NAS-PRODUKTIV aber mit 8 GByte ECC DRAM

NAS-IMAGES: Wie NAS-PRODUKTIV aber mit 4 x 3 TByte WD RED (30EFRX) und 10.2.0.2 - Prester (revision 1868)

Joerg
experienced User
experienced User
Posts: 134
Joined: 06 Dec 2014 17:53
Location: Deutschland, Peine
Status: Offline

Re: Problem: "the primary GPT table is corrupt or invalid"

Post by Joerg »

wenn du von usb oder ssd startest, sollte es nicht hängen bleiben, egal ob die 2 platten formatiert sind oder nicht.
Oder hast du die vor dem usb stick/ssd im bios als boot medium?

verdammt, grad lief die 9.3 n4f top, jetzt hängt sich das miststück ständig auf, pff^^
NasBox1: AsRock B75 Pro3, Intel Celeron G1610, 8GB Kingston KHX1600C10D3/8GX, Platinum 2GB usb2 stick. 3x 3TB WD Red, 3x 4TB WD Red, 9.2.0.1.972 X64 embedded

NasBox2: AsRock B75 Pro3, Intel Celeron G1610, 8GB Kingston KHX1600C10D3/8GX, Sandisk Extreme 32gb usb3 Stick. 1x 2TB WD Red, 1x 4TB WD Red, 9.3.0.2.1283 X64 embedded

raaalf
experienced User
experienced User
Posts: 80
Joined: 17 Dec 2014 12:45
Status: Offline

Re: Problem: "the primary GPT table is corrupt or invalid"

Post by raaalf »

Servus Jörg,

N4F ist bei mir auf einer CF-Karte installiert, da das Motherboard einen CF-Karten-Leser hat. Die CF-Karte ist im BIOS als erstes Boot-Medium eingetragen. Das BIOS stoppt, sobald der MBR der beiden angeschlossenen Festplatten nicht mehr vorhanden ist.

Das Problem hatte ich bereits ganz am Anfang bei der N4F-Installation mit einer alten 250 GByte-Festplatte. Das Problem konnte dadurch gelöst werden, indem beim Formatierten die Option "MBR (Master Boot Record) nicht löschen" aktiviert wurde. Leider gibt es jetzt beim Formatieren des RAID-1 wieder das Problem, das der MBR offenbar gelöscht oder übershrieben wird und das BIOS stoppt.

Ich bin am überlegen, ob ich das RAID 1 auflöse. Wenn ich die Festplatten normal einrichte, habe ich keine korrupte Partitionstabellen dafür aber keine Ausfallsicherheit mehr. Hm...

Grüsse

Ralf
Joerg wrote:wenn du von usb oder ssd startest, sollte es nicht hängen bleiben, egal ob die 2 platten formatiert sind oder nicht.
Oder hast du die vor dem usb stick/ssd im bios als boot medium?

verdammt, grad lief die 9.3 n4f top, jetzt hängt sich das miststück ständig auf, pff^^
NAS-PRODUKTIV: HP ProLiant MicroServer N54L | MicroServer Remote Access Card | 16 GByte ECC DRAM (Kingston KVR1333D3E9SK2_16G) | 3 x 3 TByte WD RED (30EFRX) | 9.2.0.1 Shigawire (Revision 972), x64 Embedded

NAS-BACKUP: Wie NAS-PRODUKTIV aber mit 8 GByte ECC DRAM

NAS-IMAGES: Wie NAS-PRODUKTIV aber mit 4 x 3 TByte WD RED (30EFRX) und 10.2.0.2 - Prester (revision 1868)

Joerg
experienced User
experienced User
Posts: 134
Joined: 06 Dec 2014 17:53
Location: Deutschland, Peine
Status: Offline

Re: Problem: "the primary GPT table is corrupt or invalid"

Post by Joerg »

Hey Ralf,
hast du die platten im Bios als bootmedium gelöscht?, ich mach es immer so das ich deaktiviere was ich nicht brauche.
z.b. hab ich ebend auch eine frische wd red angeschlossen, die natürlich promt an erster stelle als bootmedium stand ;)
NasBox1: AsRock B75 Pro3, Intel Celeron G1610, 8GB Kingston KHX1600C10D3/8GX, Platinum 2GB usb2 stick. 3x 3TB WD Red, 3x 4TB WD Red, 9.2.0.1.972 X64 embedded

NasBox2: AsRock B75 Pro3, Intel Celeron G1610, 8GB Kingston KHX1600C10D3/8GX, Sandisk Extreme 32gb usb3 Stick. 1x 2TB WD Red, 1x 4TB WD Red, 9.3.0.2.1283 X64 embedded

Post Reply

Return to “Deutsch”