Nachdem ich gestern schon im Chat mit Devil und einigen anderen sprach, möchte ich hier mal das Problem schildern und einen Zwischenstand geben.
Das ganze ist mir mehr als suspekt!
Ich habe auf eine neue ssd (Vertex3, Sata3 an Sata 2 angeschlosen) siduction installiert. Während des Installationsprozesses war meine Datendisk1 (3Tbyte) mit angeschlossen. diese wurde seinerzeit mit parted formatiert und ein gpt angelegt.
Nun gehts los:
Nach der Installation ist diese Platte nicht mehr mountbar. gparted zeigt, das kein Dateisystem darauf vorhanden ist.
fdisk erkennt sie als 3Tbyteplatte und ein manueller mount sagt:
special device sdd1 kann nicht gemountet werden.
Daraufhin habe ich meine Backupplatte (identischer Typ) angeschlossen. Diese war bei der Installation nicht im System angeschlossen. Und auch diese lässt sich nicht mounten!
Schließe ich diese mit einem externen USB-Sata-Adapter an, meldet fdisk -l dass sie nur 800 GByte habe:
Quote
Disk /dev/sdg: 801.6 GB, 801568644608 bytes
255 heads, 63 sectors/track, 97451 cylinders, total 1565563759 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdg1 1 4294967295 2147483647+ ee GPT
Devil rät mir zu Testdisk - aber bevor ich etwas an den Platten verändere, und schreibend drauf zugreife, will ich erst noch Infos einholen.
Was meint ihr...?
lanzi, im Forum hast Du gestern einen Link bekommen, die Settings, die in dem Link angegeben waren, würde ich mal prüfen.
Meinst Du im Chat? Im Forum habe ich keine Antwort erhalten.
im Chat der Link, war doch nur ein allgemeines formatieren und mounten von gpt Laufwerken. die option mount -t ext4 brachte nichts.
Oder meintest Du einen anderen Link?
Dann bitte nochmal posten. ich habe keinen Zugriff mehr drauf, da es entweder von der LiveCd oer vom Notebook aus war.
Danke!
[Saturday, January 14, 2012] [12:45:14 AM] <premix_> Lanzi2: sieh mal hier: http://www.pjc.me.uk/efi-gpt/index.html
Hi Lanzi,
wenn du mit GPT hantierst würde ich statt fdisk, dir gdisk wärmstens an's Herz legen.
GPT fdisk text-mode partitioning tool
GPT fdisk (aka gdisk) is a text-mode partitioning
tool for that works on Globally Unique Identifier
(GUID) Partition Table (GPT) disks, rather than
on the more common (through 2009)
Master Boot Record (MBR) partition tables.
@Blulupo.
Danke fürs Feeedback.
ja, es ging ja auch nur um einen kurzen Überblick. Mit gdisk habe ich die Partitionsdaaten noch nicht ausgelesen, da ich nicht weiß wie. Ich finde kein gegenstück zu "fdisk -l".
@agaida: Danke, den hatte ich gestern als mountbefehl getestet, aber nicht den oberen Teil abgearbeitet. Erfolgt gleich nach dem Neustart.
@all
Meine grundsätzlichen Probleme sind:
1. Was und warum hat sich geändert, dass zwei vorher lesbare Platten, eine davon zu 100% ohne Veränderung (einzig einmal wurde fdisk -l aufgerufen) plötzlich weder unter siduction noch dem alten System lesbar sind. Das ist doch absurd...
2. Oder sind sie noch lesbar und es liegt ein anderer Defekt vor?
Kabel wurden geprüft - die Platte wurde an mehreren Stata-Port des gleichen Rechners getestet und auch über USB angeschlossen. Dazu alles unter aptosid, siduction und entsprechend beiden Livesystemen.
Der Test an einem anderen Rechner folgt als nächstes.
man gdiskQuotegdisk - Interactive GUID partition table (GPT) manipulator
SYNOPSIS
gdisk [ -l ] device
.....
http://www.rodsbooks.com/missing-parts/index.html
Könnte weiterhelfen. Auf jedenfall sind da ein paar Sachen aufgelistet, die Du einfach überprüfen kannst.
Der Titel des Threads ist auch leicht irreführend, die Platten warden erkannt, die Partitionen warden erkannt, Du kannst "nur" nicht mounten. So rein nominell ist alles ok.
Bei dem verlinkten Artikel war nicht das Mounten an sich interessant. Interessant war der cat und die überprüfung der Ausgabe:
agaida@siductionvm:/boot$ cat config-3.1-6.towo.2-siduction-amd64 | grep EFI
CONFIG_EFI=y
CONFIG_FB_EFI=y
CONFIG_EFI_VARS=y
CONFIG_CACHEFILES=m
# CONFIG_CACHEFILES_DEBUG is not set
# CONFIG_CACHEFILES_HISTOGRAM is not set
CONFIG_EFI_PARTITION=y
Falls mich jemand darauf hinweisen will, das dieser cat sinnfrei ist und ich damit ein Anwärter für den "Useless Use of Cat Award" bin, nur zu, das ist ein Zitat und ich wollte nichts ändern.
Fakt ist aber, dass sie zu setzenden Schalter gesetzt sind und der Kernel als Übeltäter damit erst mal ausfällt.
So agaida und alle anderen, ich arbeite jetzt mal alles der Reihe nach ab:
Am Ende noch eine vermutung meinerseits.
Mittlerweile ist die PLatte in einem anderen Rechner unter aptosid - auch hier kein mounten möglich (Betreff wird geändert - hast recht!)
Ausgaben von mount
Quote
mount /dev/sdb1/ /mnt/sdb1
mount: special device /dev/sdb1/ does not exist
fdsik -l
Quote
Disk /dev/sdb: 3000.6 GB, 3000591900160 bytes
255 heads, 63 sectors/track, 364801 cylinders, total 5860531055 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdb1 1 4294967295 2147483647+ ee GPT
Partition 1 does not start on physical sector boundary.
parted /devsdb print
Quote
root@server:/home/h# parted /dev/sdb print
Error: Invalid argument during seek for read on /dev/sdb
Retry/Ignore/Cancel? i
Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used.
OK/Cancel? ok
Backtrace has 8 calls on stack:
8: /lib/x86_64-linux-gnu/libparted.so.0(ped_assert+0x2e) [0x7ffe75513f3e]
7: /lib/x86_64-linux-gnu/libparted.so.0(+0x44712) [0x7ffe75544712]
6: /lib/x86_64-linux-gnu/libparted.so.0(ped_disk_new+0x58) [0x7ffe7551a0b8]
5: parted() [0x407401]
4: parted(non_interactive_mode+0x8c) [0x40e00c]
3: parted(main+0x1407) [0x406ae7]
2: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7ffe74d31ead]
1: parted() [0x406bad]
You found a bug in GNU Parted! Here's what you have to do:
Don't panic! The bug has most likely not affected any of your data.
Help us to fix this bug by doing the following:
Check whether the bug has already been fixed by checking
the last version of GNU Parted that you can find at:
http://ftp.gnu.org/gnu/parted/
Please check this version prior to bug reporting.
If this has not been fixed yet or if you don't know how to check,
please visit the GNU Parted website:
http://www.gnu.org/software/parted
for further information.
Your report should contain the version of this release (2.3)
along with the error message below, the output of
parted DEVICE unit co print unit s print
and the following history of commands you entered.
Also include any additional information about your setup you
consider important.
Assertion (last_usable <disk>dev->length) at ../../../libparted/labels/gpt.c:718 in function
_parse_header() failed.
Aborted
cat /boot/config-3.1-4.slh.3-aptosid-amd64 | grep EFI
Quote
CONFIG_EFI=y
CONFIG_FB_EFI=y
CONFIG_EFI_VARS=y
CONFIG_CACHEFILES=m
# CONFIG_CACHEFILES_DEBUG is not set
# CONFIG_CACHEFILES_HISTOGRAM is not set
CONFIG_EFI_PARTITION=y
Quote
Zu guter Letzt die Ausgabe von gdisk - welche einen Hinweis gibt
Quote
root@server:/home/h# gdisk -l /dev/sdb
GPT fdisk (gdisk) version 0.8.1
Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.
Warning! One or more CRCs don't match. You should repair the disk!
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged
****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
Disk /dev/sdb: 5860531055 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 8672F6E9-7B54-483B-9A0A-85CA11830F5A
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2925 sectors (1.4 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 5860532223 2.7 TiB 0700 primary
Diese Meldung habe ich bei beiden Disks...
So, und nun mal doof in die Runde gefragt. Kommen Vertex3 ssd mit einer NTFS Formatierung? Die war nämlich drauf - sonst nichts.
Meine war von Avides als Amazonhändler und angeblich gebraucht - allerdings war das Siegel der Plastiktüte okay.
Besteht die Möglichkeit, dass ich mir mit der ssd einen mbr Virus geholt habe, der auf die HDDs gegangen ist und deren gpt zerstört hat?
Denn offensichtlich ist ja der gpt korrupt.
was nun?
Hi Lanzi,
in Deinem ssd-Thread schreibst Du
Quote...und sie nach Devils Anleitung mit gdisk und gpt formatiert.
..das System startet nicht!
..fdisk...
Also mit mbr Formatierung lässt sich siduction starten!
GPT brauchst Du aber, um die Größe Deiner anderen Platte(n) anzusprechen.
QuoteMit der GUID Partition Table führt es einen flexibleren Nachfolger für auf dem Master Boot Record basierende Partitionstabellen ein. Die GPT ist notwendig, um von einer Festplatte > 2 TB booten zu können, bzw. Partitionen > 2 TB anlegen und verwalten zu können.
Quelle: http://de.wikipedia.org/wiki/UEFI
http://de.wikipedia.org/wiki/GUID_Partition_Table
@unklarer
ich hatte vorher auch eine SSD im System (aus dem Kopf meine ich, dass sie normal mit fdisk formatiert ist) und wenn ich von dieser als System starte oder von einer Live CD geht die HDD auch nicht mehr. Sie ging aber gestern noch mit diesem System!
Da ich nicht von 3 TByte platten boote, sollte also alles mit mbr okay sein, oder übersehe ich da was?
Ja, und Du hast Dir keinen Virus etc. eingefangen.
QuoteMBR-Partitionstabelle
Im ersten Sektor/Block des Datenträgers (LBA 0) befindet sich der Master Boot Record (MBR). Dort befindet sich eine klassische MBR-Partitionstabelle mit einem Eintrag, der den Rest des Datenträgers belegt. Für ein Betriebssystem, das nur MBR- aber keine GPT-Partitionstabellen lesen kann, erscheint der gesamte Platz des Datenträgers als belegt. Dieser MBR stellt einen Schutz für den Inhalt des Datenträgers dar, falls auf diesen mit alten Partitionierungstools, die das GPT-Schema nicht kennen, zugegriffen wird.
Ergo, alles wieder wie zu deinem ssd-Thread
"...das System startet nicht..."
zusammenbauen.
Bei mir war der Fehler (altes Bios, kein (U)EFI), die ssd mußte einfach das BootFlag * gesetzt bekommen. :wink:
Quoteoder übersehe ich da was?
Quotebzw. Partitionen > 2 TB anlegen und verwalten zu können.
hmmm,
also das ganz ursprüngliche System bekomme ich nicht hin, da mein Aptosid von der ursprünglichen SSD aus nicht bootet. vermutlich ist dessen Booteintrag mit der siductioninstallation auf Grub der neuen SSD "gerutscht".
Wenn ich aber mit beiden SSDs boote, und dann von der alten das Aptosid-System starte, werden die Hdds nicht erkannt.
Die oben geposteten Daten sind übrigens von meinem Server in dem auch zwei 3 Tbyteplatten werkeln. nun habe ich diese zum Auslesen von agaidas Werten abgestöpselt und die anderen dran, und sie werden nicht erkannt...
Das widerspricht alles ein wenig der Theorie, dass die boot-SSd gpt haben muss, um auf weitere gptplatten zugreifen zu können...
Zu Deinem Tipp mit dem Bootflag. Sollte der bei der neuen ssd gesetzt werden (siduction), oder bei der alten (aptosid), welche ja alleine nicht mehr bootet?
Quote from: "Lanzi"Das widerspricht alles ein wenig der Theorie, dass die boot-SSd gpt haben muss, um auf weitere gptplatten zugreifen zu können...
Nein, Du verstehst da was falsch.
Die SSD hat mit dem Problem nichts zu tun.
Du mußt Deinen Rechner mit EFI booten, weil nur das und nicht das herkömmliche Bios mit Deinen TB-Platten umgehen kann.
Deshalb schreibt auch devil in seinem Wiki-Artikel zuerst von der gpt-Einrichtung mit Hilfe von
gdiskund später weiter unten von der herkömmlichen... mit Hilfe von
fdiskm.E. hast Du Dir die Probleme nur bereitet, weil Du nach dem "Nicht Starten des Systems von SSD"
anschließend gleich wieder mit fdisk alles zunichte gemacht hast.
Mit dem Tipp...
ursprünglich habe ich ja auch mal gedacht, Linux brauch diese Markierung
bootnicht.
Ich stand vor dem selben Problem und hab stundenlang die Tante befragt. Ich weiß auch nicht, ob es für jeden Fall gilt. Da es sich bei mir um ein x40 handelte und die Rechner von Haus aus nur mit WIN kommen, meinte vielleicht das Bios nicht mitarbeiten zu wollen, weil es das boot erwartete...
Das stimmt so nicht. GPT setzt kein UEFI voraus.
Manches BIOS braucht ein Bootflag, das ist richtig, und es ist immer einen Versuch wert.
greetz
devil
Danke devil, für die Richtigstellung.
Ich bin tatsächlich von einer Gleichstellung ausgegangen. Lanzi hat jedoch nicht einmal EFI erwähnt.
@Lanzi
mein Satz muß richtig lauten:
QuoteDu mußt Deinen Rechner mit GPT booten, weil...
:)
Danke Euch beiden. Ich schau morgen mal.
im Übrigen habe ich auch kein EFI... ging ja auch bisher ohne.
Ich probiere es morgen mit dem Bootflag mal aus.
Da die neue SSD jetzt mit fdisk und mbr formatiert wurde, wäre der korrekte Weg also mit gdisk neu formatieren, Bootflag setzten und siduction installieren, ja?
Was ich bei alldem nicht verstehe, warum wird weder die normale Daten HDD noch die Backup-HDD in einem anderen Rechner gemountet (siehe Fehlermeldung auf der Vorseite mit defektem gpt-Eintrag), der auch sonst 2 3TByte HDDs drin hat (mit parted erstellt). Denn der andere Rechner hat ja nun wirklich nichts mit der SSD zu tun.
Falls das mit dem Bootflag nicht geht, werde ich morgen erstmal ne neue 3 Tbyte HDD ordern und mit DD eine kopie für weitere Versuche mit testdisk und den Reperaturmechanismen von gdisk erstellen.
Also die neue SSD mit gpt formatiert und mit gparted das Bootflag gesetzt. Siduction installiert.
Fazit: Das System startet nicht.
Hätte mich auch gewundert, da meine alte SSD ja auch mit fdisk formatiert wurde (mbr).
Trotzdem danke Unklarer. Ein Versuch wars wert.
Ich denke wir sollten uns nochmal die Ausgabe von gdisk der vorherigen Seite ansehen:
Quote
root@server:/home/h# gdisk -l /dev/sdb
GPT fdisk (gdisk) version 0.8.1
Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.
Warning! One or more CRCs don't match. You should repair the disk!
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged
****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
Wenn ich das verify und recovery von gdisk nutze, dann greife ich ja schreibend auf die Disk zu, was ich bisher vermieden habe. Hat jemand damit Erfahrungen? Oder sollte ich einen anderen Weg einschlagen.
Dienstag kommt meine Erstaz HDD, auf die ich alles clonen möchte, sollte ich solange warten?
Das Problem ist, dass ich recht dringen eine Datei der Platte brauche...
Noch eine praktische Frage: um bei kopieren mit DD nicht durcheinander zukommen, sollte ich die Platte (die alte und die neue am Dienstag) nicht verwechseln. Praktische Tipps? Ist dd mit UUID möglich?
Hi Lanzi,
tut mir Leid, jedoch blicke ich bereits nicht mehr durch!
m.E. tut
gpt nichts formatieren und was willst Du mit verify und recovery?
Quote from: "Lanzi"Wenn ich das verify und recovery von gdisk nutze, dann greife ich ja schreibend auf die Disk zu, was ich bisher vermieden habe. Hat jemand damit Erfahrungen? Oder sollte ich einen anderen Weg einschlagen.
Dienstag kommt meine Erstaz HDD, auf die ich alles clonen möchte, sollte ich solange warten?
Das Problem ist, dass ich recht dringen eine Datei der Platte brauche...
Noch eine praktische Frage: um bei kopieren mit DD nicht durcheinander zukommen, sollte ich die Platte (die alte und die neue am Dienstag) nicht verwechseln. Praktische Tipps? Ist dd mit UUID möglich?
Irgendwo hatte ich von Dir gelesen, dass Du die Platte gebraucht von einem Händler bei Amazon gekauft hast (hab ich ja auch gemacht :wink: ) und sie sei mit ntfs formatiert gewesen.
Ich schlage Dir vor, alles zur SSD in Deinem anderen Faden fort zu führen. Hier heißt Dein Thema ..3TB-Platten...
Tut mir leid, wenn ich Dich verwirrt habe. :-)
Das Problem liegt nicht in den SSDs... die gehen. Mein Problem ist, dass ich eine neue SSD mit siduction bespielt habe und meine beiden 3TB HDDs sich nicht mehr mounten lassen.
ich hatte die SSDs nur nochmal ins Spiel gebraucht, weil Du meintest, dass es an denen liegen könne. Aber da haben wir uns wohl sowieso falsch verstanden.
Edit: verify und recover beziehen sie auf die letzte Codebox, welche eine Ausgabe mit einer Fehlermeldung von gdisk beschäftigen, welche ich weiter oben und auf S. 1 gepostet habe.
Lanzi,
lies mal bitte http://www.rodsbooks.com/gdisk/repairing.html
Vielleicht klingelt da was.
greetz
devil
@Devil:
Danke dass Du noch mitliest. Ist alles sehr frustrierend... Ein ganzes WoE drangehängt - ohne dass ich mir bewusst bin irgendwas falsch gemacht zu haben, noch dass ich den gemachten Fehler einkreisen kann. Dazu jetzt 180 Euro für ne Rettungsdisk und nicht mal die Hoffnung meine Daten schnell wiederzusehen!
Es kann einfach nicht sein, dass bei zwei HDD-Disk gleichzeitig der gleiche Fehler auftritt, wenn noch nichtmal beide angeschlsossen waren. Irgendwas wesentliches übersehen wir alle noch!
Ich hege den verdacht eines Virus, oder das gdisk einen bösen bug hat.
Zu Deinem Link:
Ja, habe ich gestern schon gelesen. Agaida hatte ihn gepostet. Danach werde ich vorgehen, wenn ich die HDD geklont habe.
Ich traue mich nur nicht momentan dran, weil ich keine Erfahrung damit habe und bevor ich wild rumteste brauche ich ein mit dd erstellten Klon!
Wenn ich jetzt sicher wüsste, dass das revovery keinesfalls meine Daten gefährdet oder die Sache verschlimmert, würde ich es heute tun, aber diese bestätigung wird mir wohl niemand geben können...
Hast Du denn überhaupt sichergestellt, dass nicht nur die Partitionstabelle kaputt ist?
greetz
devil
Ja ich denke sowas wirds sein.
gparted meldet
Partition: nicht zugeteilt
Dateisystem: nicht zugeteilt
gdisk meldet:
Quote
GPT fdisk (gdisk) version 0.8.1
Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.
Warning! One or more CRCs don't match. You should repair the disk!
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged
****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
Wenn Du noch mehr Ausgaben brauchst sag bescheid. Ich kann auch in den Chat kommen.
Hi Lanzi,
da bin ich aber froh, nur verwirrt zu sein. Ich hatte schon gedacht, für mein Alter nun nicht mehr mithalten zu können. :wink:
Spaß beiseite...
Ich habe diesen Faden nun noch einmal von Anfang an gelesen.
Dabei fällt mir auf, daß Du das System / die Platten mit 4 verschiedenen Tools mitlerweile bearbeitet hast.
- gdisk
- fdisk
- gParted
- parted
Für das, was Du vor hast, eignet sich nur gdisk. Ich denke, darüber herrscht Einigkeit. Die anderen drei können mit dem, was gdisk macht, später nicht umgehen (ist zumindest mein gegenwärtiger Kenntnisstand und ich könnte da auch nicht weiterhelfen).
Abgesehen davon, daß die GPT-Partitionstabelle kaputt ist, hast Du auch nicht einmal anfangs z.B. dem devil, der sich damit bestimmt mehr auskennt, die Ausgabe vongdisk -p /dev/sd(x)
oder mit dem Parameter -i (müßte auch gehen)hier eingestellt.
Wahrscheinlich wird Dir nach der Datensicherung nichts anderes (und auch einfacheres) übrig bleiben, als alles noch mal NEU anzulegen.
Lanzi,
schau halt mal mit testdisk drauf. Das stellt Partitionstsabellen wieder her.
greetz
devil
Ich glaube nicht, daß testdisk gpt Partitionen wiederherstellen kann.
bearbeitet habe ich die HDD bisher mit keinem Tool. Nur Infos ausgelsesen. gpt können sowohl parted als auch gdsik. Die 3 TByte HDD wurde mit parted erstellt.
Die Ausgabe von gdisk ist auf s.1 gepostet und dann noch zwei weitere Male weiter oben:
Quote
root@server:/home/h# gdisk -l /dev/sdb
GPT fdisk (gdisk) version 0.8.1
Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.
Warning! One or more CRCs don't match. You should repair the disk!
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged
****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
Disk /dev/sdb: 5860531055 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 8672F6E9-7B54-483B-9A0A-85CA11830F5A
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2925 sectors (1.4 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 5860532223 2.7 TiB 0700 primary
@devil & towo:
werde vermutlich morgen als erstes, nach dem clonen auf eine neue HDD (wenn das innerhalb eines Tages zuende ist...) mit den recoverymethoden von gdisk beginnen. b Testdisk gpt kann ist natürlich eine interessante Frage...
Testdisk kennt GPT grundsätzlich, weil es die beim Mac auch reparieren kann. Aber ein Versuch macht nichts kaputt, entweder er erkennts oder nicht.
greetz
devil
Bei GPT sind die Partitionsdaten hinten auf der Platte nomal geclont (weswegen mit GPT keine Partition bis zum hinteren Anschlag es schafft). Mit gfdisk gibt es einen Expertenmodus, mit dem man diesen hinteren Clone der Partitionsdaten vorne wieder reinschreiben kann.
Viele machen sich die GPT Eintragungen mit grub ins MBR kaputt. Grub ins MBR geht nicht (oder besser gesagt: überschreibt), weil eben GPT mehr Partitionsdatenplatz braucht als die alte MBR Partitionierung. Das ist auch der Grund warum man mit GPT unendlich viele Partitionen auf unendlich großen Platten packen kann.
Da grub ins MBR nicht geht bei GPT, und es nicht zukunftsicher ist mit --force in eine /root Partition zu schreiben (es könnten Optimierer kommen, die Daten umsortieren), bietet sich eine /efi oder /boot Partition an zu nehmen.
Quote from: "Lanzi"ob Testdisk gpt kann ist natürlich eine interessante Frage...
mußt aber ab einer bestimmten Version achten:
http://www.cgsecurity.org/wiki/Gegenw%C3%A4rtige_Einschr%C3%A4nkungen
Warum wollt Ihr aber testdisk benutzen, wenn er http://www.rodsbooks.com/gdisk/repairing.html
(hier von Euch gepostet) angibt, das auch zu können?
Das kann ich besser lesen/verstehen (gebe ich ja zu :wink: )
QuoteDie sekundäre GPT am Ende des Datenträgers ist eine Kopie der primären GPT am Anfang des Datenträgers. Durch diese Redundanz kann im Fehlerfall die Partitionstabelle wiederhergestellt werden. Da in der GPT eine Prüfsumme eingetragen wird, kann festgestellt werden, welche der beiden GPT konsistent ist.
http://de.wikipedia.org/wiki/GUID_Partition_Table
Edit: ralul war schneller.
Wäre interessant, zu sehen ob es geht. (bei beiden).
greetz
devil
So, mal sehen, wer sich mit mir traut...
Also, die bestellte festplatte braucht wohl noch ein paar Tage und da ich in Zeitnot bin, muss ich was riskieren...
Also, ich werde die folgenden Versuche an der Backup-Datendisk vornehmen (gehen ja beide nicht - identische Fehler):
Starten von gdisk:
Quote
GPT fdisk (gdisk) version 0.8.1
Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.
Warning! One or more CRCs don't match. You should repair the disk!
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged
****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
Also ist wohl der Backup-header defekt... Aber warum wird dann die Disk nicht erkannt, wenn es nur der Backup-header ist?
Als nächstes habe ich den Main-Header mit der Option b gespeichert.
Jetzt habe ich ein disk-verify durchgeführt:
Quote
Command (? for help): v
Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.
Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.
Problem: Disk is too small to hold all the data!
(Disk size is 5860531055 sectors, needs to be 5860533168 sectors.)
The 'e' option on the experts' menu may fix this problem.
Problem: partition 1 is too big for the disk.
Identified 4 problems!
Es wird ja auf http://www.rodsbooks.com/gdisk/repairing.html gewarnt, dass der Bericht etwas negativ ausfallen kann...
Allerdings bin ich jetzt am zweifeln, was ich tun soll...
die folgenden Optionen stehen zur Verfügung:
Quote
Recovery/transformation command (? for help): ?
b use backup GPT header (rebuilding main)
c load backup partition table from disk (rebuilding main)
d use main GPT header (rebuilding backup)
e load main partition table from disk (rebuilding backup)
uvm...
Wenn jemand fit ist, bitte ich um einen Tipp...
Edit: da ich normal nach dem start von gdisk mit der Partition arbeiten kann (Semi-Automated Recovery) und er den gpt selbst wählt und die Daten richtig angezeigt werden, könnte vielleicht ein einfaches w (write) schon reichen???
Du musst irgendwie wissen welche Partitionierungsdaten plausibel sind und dann alles schreiben und harmonisieren. Wenn du die Plausibilität nicht weisst, wird es schwierig
wenn du:
- zwischendurch was mit anderen Tools gemacht hast
- mit anderen Tools eine zu lange Partitions bis ans Ende geschrieben hast, so dass der GPT-Backup-Header manipuliert worden ist.
- mit gfdisk was gemacht hast, was den GPT-Backup-Header manipuliert hat.
- mit falschen Partitionsdaten etwas formatiert hast.
Ich glaube nicht, dass (mbr)-fdisk von sich aus in den GPT-Backup-Header schreibt, weil dieser Header dem fdisk unbekannt ist, denn solcherart Backup gab es nicht mit MBR. Ich habe den langen Thread nicht mehr im Kopf, weiss also nicht auf welchem Stand dein Platte ist ...
Es nützt natürlich nichts, wenn du im Expertenmodus den Backup-Header holst, aber nicht mit write das Programm gdisk aufhörst, dann war es für die Katz temporär ...
Hi ralul,
ich habe im Grunde garnichts mit den Platten gemacht. Davon gehe ich immer noch aus. Was ich mir denken könnte, dass bei der Installation von siduction grub auf die platte zugegriffen hat und versucht hat einen mbr zu schreiben.
- sonst hatte ich weder mit fdisk noch mit gdsik bisher Zugriff...
- Partitionen wurden nicht geschrieben
... Wenn du mit der siduction Installation einen grub ins MBR geschrieben hast, ist die Vorne-GPT-Partitionierung überschrieben.
Wenn der Backup-Header in Ordnung ist kannst ihn schreiben ... und danach nochmal gdisk starten und verify
Meiner Ansicht nach, wenn die Partiton den richtigen Anfang hat:
- macht es nicht mal etwas, wenn die Partition länger ist als (mit ext4) formatiert
- wenn die Partition kürzer ist, weiss ich nicht wie der Kernel reagiert
Ja, das ist meine vermutung...
AAAAber: die erste Meldung von gdisk ist:
Quote
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.
Das widerspricht ja meiner Vermutung.
Jetzt ist die Frage, ob die Fehlermeldung nicht einfach falsch ist. Denn, wenn der Backup-header wirklich defekt ist, müsste die Disk doch trotzdem laufen...
vlt. sollte ich doch erst ein clon erstellen...
Ähm, ich habe keine Ahnung von dem gfdisk-Teil und verstehe bestimmt auch nicht mal die Hälfte...
Diese Warnung erhälst Du doch durch Aufruf von v, was die erste Ebene ist.
Wir sind uns einig, dass das Ding repariert werden muß. Wäre es dann von der Logik her nicht r und dann v in der Zweiten, um vielleicht noch mehr Ifo zu bekommen?
ühh, das hört sich ja wie ein Bug von gdisk an, allerdings nur wenn alles stimmt, was Du vorher gesagt hast!
Du kannst mit dem Progi dd allerdings doch noch an den Backup-Header rankommen und dann per Expertenmenu c einspielen.
Zwischenfrage: wie kopiere ich den gpt und den Backup-gpt mit dd?
Finde im web irgendwie nichts genaues?
man dd
ist aber kompliziert
Lanzi, sag mal:
Du hattest nur eine riesige Partition drauf auf der Platte?
Dann kannst du doch mit Plausibilität vorgehen:
- richte dir in der /etc/fstab einen "noauto,ro 0 0" Eintrag für die Platte ein.
- gdisk partitioniere die Platte neu mit einer riesigen Partition. Wenn die Partition größer als vorher formatiert ist, macht das nichts.
Wenn du den Anfang richtig triffst sollten keinen Daten verloren gehen, und du siehst mit dem root Befehl
mount /media/meine_Platte
alle Daten. Vielleicht musst du die Partitionierungsdaten,die der Kernel sieht synchroniesieren, oder einfach neu booten vorher.
Plausibilität:
2048 ist eine gute Norm für ein Anfangsdatum unter Linux, das war auch auf einer Ausgabe von dir hier im Forum.
40 ist der Anfang der ersten Partition meines Apple Mini
Du kannst beides probieren, denn wenn du nur "noauto,ro" mit "0 0" hinten in der /etc/fstab einträgst wird nichts verändert an Daten. Partitionierung ändert nichts an Daten per se!
Ralul: Ja, es ist nur eine große Partition.
Dein Tipp klingt gut. Morgen kommt hoffentlich meine Ersatzplatte, die ich dann erst clonen muss. (Habe versucht eine der beschädigten Platten auf eine 3 Tbyte USB-Platte zu clonen, das ist aber jedesmal schief gegangen (Eingabe/ Ausgabefehler, 384 Mbyte wurden kopiert).
Frag nicht warum...
Also, bis morgen, oder realistisch Freitag bin ich hier im Standby (mein Zeitdruck hat sich etwas entschärft, weil eine wichtige Datei mittlerweile noch von mir auf dem Notebook gefunden wurde).
Also, erstmal danke an alle bis hierhin... ich melde mich, sowie es Änderungen und Neuigkeiten gibt...
So, habe mit dd die komplette Platte kopiert, allerdings kam nach vielen Stunden die Meldung eines Eingabe/AUsgabe Fehlers:
xxxxxxx+1 Datensätze wurden gelesen
xxxxxxx+0 Datensätze wurden geschrieben
3Tbyte an Daten kopiert, Zeit rund 34000s
Die Meldung ist jetzt nur zusammengefasst, weil ich an einem anderen Computer kopiert habe.
Fakt ist, dass die neue kopierte Platte im Anschluss keinen (!) gpt und auch keinen Backupgpt-Eintrag hat, die ich ja gerade so reparieren wollte.... Ahhh, Frust!
Woran liegt das denn jetzt?
Also habe ich als kurzen Versuch mit gdisk o einen neuen Gpt erstellt und beim schreiben mit w meldet er einen nicht näher definierten Error!
Auf dieser neuen Platte lässt sich also auch kein neuer gpt erzeugen.
Ich schau gerade nach der versteckten Kamera... finde aber keine ;-)
Ideen?
Es gibt schon mal Platten, bei denen die Hardware einfach mal so kaputt geht. Soll es geben. ZB gerade beim openSUSE Build Server drei Platten auf einmal.
Dann kannst du die Platte vielleicht auf Garantie zurückgeben. Aber vorher würde ich noch probieren:
alles weg: o
schreiben+exit: w
Und neu!
Wenn du das alte Anfangsdatum triffst, hast Du sogar deine alten Daten wieder (Wenn die Platte nicht kaputt ist). Aber mach ganz gewiss, dass du diesmal die richtige Platte bearbeitest:
- möglichst alle anderen raus
- mit "df" prüfen was noch eingehängt ist
Zwischenstand:
Ich denke die Hardware funktioniert.
Für den dd Fehler habe ich eine mögliche Erklärung, die root-partition war durch dd vollgelaufen. Nach schaffen von mehr Platz hat er auch einen gpt gefunden. Bin gerade am experimentieren.
Melde mich bei Fortschritten!
So, ich denke, ich habe meine Daten wieder...
Meine Vorgehensweise:
Das Kopieren mit dd brachte Fehlermelduungen, wenn ich die Disk anschließend mit gdisk retten wollte:
Quote
Recovery/transformation command (? for help): e
Recovery/transformation command (? for help): w
Warning! Secondary partition table overlaps the last partition by
1202 blocks!
You will need to delete this partition or resize it in another utility.
Problem: partition 1 is too big for the disk.
Aborting write operation!
Aborting write of new partition table.
Da gibts auch iorgendwie keinen Ausweg... alle Änderungen die ich am gpt vornehmen möchte sind nicht möglich - bei Orginaldatendisk und Backupdisk - da ich abschließend nicht schreiben kann...
Werde Raluls Methode noch testen.
Daraufhin habe ich eine leere 3Tbyte Disk mit parted formatiert (genauso, wie ich es damals auch gemacht hatte.
Quote
parted /dev/sdx
mklabel "gpt"
unit %
mkpart primary 0% 100%
quit
Dann habe ich wieder einen Durchgang mit dd gestartet und die Originaldisk kopiert.
Der Clon lässt sich nun ganz normal mounten...
puhhh...
Mein Fazit: Logik habe ich in alledem nicht gefunden:
- Weder weiß ich warum zwei Platten ihren gpt verloren haben (eine war nicht angeschlossen),
- noch versteh ich die widersprüchlichen Meldungen von gdisk wonach mal der gpt mal der backup-gpt defekt sein sollen
- noch weiß ich, warum die Partitionen angeblich zu groß sein sollen und ein schreiben nicht möglich ist.
Das ganze kostete mich eine Woche, 180 Euro und sehr viele Nerven!
Ich möchte recht herzlich allen beteiligten Helfern hier im Forum für Fachwissen, Geduld (!) und Beistand danken!!!
Durch Euch wird der begriff "Community-Os" mit Leben gefüllt. Danke!
So, ich werde jhetzt erstmal den Clon auf Herz und Nieren prüfen...
Schönes WoE allen!
Ich verstehe leider auch kein bisschen von dem Ganzen. Ich kann mir nur vorstellen, dass uns ein Puzzleteil, dass du vll. für unwichtig hälst, fehlt. Ich habe versucht, ähnliche Fehler im Netz zu finden, leider ohne Erfolg.
greetz
devil
klar, das ist immer möglich... Aber andererseits, bin ich in diesem Gebiet auch nicht so unbewandert, nur gpt ist für mich neu.
Ich hatte ja auch eine Woche Zeit alles zu durchdenken. Ich hatte z.B. keine Bios-Änderungen vorgenommen. Bewusst (!) die Backup-platte entfernt, als ich siduction einspielte und so weiter.
ich denke auch, dass uns ein Puzzleteil fehlt... Ich tippe mal auf eine Kombination mehrerer Bugs...
Noch eine Anmerkung:
habe zu testzwecken eben mal eine der nicht mountbaren Platten mit parted neu eingerichtet, ohne sie zu formatieren:
Also:
parted /dev/sdx
mklabel "gpt"
unit %
mkpart primary 0% 100%
Dann neu gestartet. Von gparted wir die Platte korrekt nun angezeitgt, auch das Platten-label stimmt, aber nach wie vor kann ich sie nicht mounten:
Quote
special device dev/sda1 does not exist
@Lanzi, erfahrene Nutzer haben normalerweise die richtigen "Reflexe", wie ageida gerne sagt. Was heisst, wenn man das gefährliche dd Tool schon benutzen muss, dann schaut man die Größen vorher ganz genau an.
Was ich damit sagen will: Wenn Du Dir nicht solche Reflexe angewöhnen kannst, dann lass die Finger von LowLevel. Reflexe Beispiele, die dir fehlen:
- dd Größen ganz genau vorher anschauen
- dev/sda1 ist relativ, nicht von überall her zu finden wie /dev/sda1
- beim Installieren ganz genau Geräte prüfen, unnütze Geräte abnehmen
- beim Fehlerfall erstmal auf Null stellen und nicht gleich highlevel parted, siehe http://forum.siduction.org/index.php?msg=16002&sid=0a37d7cc33c5bc165571359a8f364c1c#16002
@ralul:
Verstehe ich ehrlich nicht gesagt nicht ganz, was Du damit meinst.
Die unterschiedlichen Größen hatte ich bei den beiden defekten Platten. Sie werden nur von gdsik gemeldet. Übrigens, wie ich seit vorhin weiß auch, wenn man eine normale Partition mit fdisk oder parted erstellt und diese dann spaßeshalber mal mit gdisk und der Option verify prüft. Selbst dann meckert gdisk über unterschiedliche Größen.
Zum gefährlichen tool dd:
ich nutze es seit mindestens 10 Jahren - und ich sehe ehrlich gesagt keine andere kluge Option, eine defekte Festplatte zu untersuchen, indem ich einen clon davon mit dd erstelle und dann am clon meine Experimente starte.
Ich stimme Dir aber zu, dass dd gefährlich ist.
zu dev/sda1 - jo, das war ein Tippfehler, aber auch eine korrektur mit mount /dev/sda1 bringt die gleiche (!) Fehlermeldung.
"Beim Installieren ganz genau Geräte prüfen, unnütze Geräte abnehmen"
Ja, sehr wahr! Hätte mir vermutlich die Orgie auch nicht erspart, da die Backupdisk wie gesagt ab war, und trotzdem nicht mehr ging...
Die vierte Aussage verstehe ich garnicht.
Diesen Weg bin ich wie oben beschrieben gegangen, aber ich konnte mit gdisk eben nicht schrieben (Option w)...
ich danke Dir für Deine zeit und Geduld, ralul. Deine Ideen waren sehr hilfreich, überhaupt einen Teil des ganzen Vorfalls zu durchblicken.
Jo, vielleich hast du recht, weil wenn gdisk buggy ist...
Oder bei dir ist etwas Hardware mäßig nicht in Ordnung, ein Usb Anschluß oderso, wenn du schreibst: "da die Backupdisk wie gesagt ab war, und trotzdem nicht mehr ging... "
@Ralul:
Ist müßig nach Ursachen zu suchen, kannst mir aber glauben, das ich nicht DER Anfänger bin, so wie es den Eindruck hat..., auch wenn eine gewisse Schusseligkeit (siehe den fehlenden Slash vorkommt) ;-)
Ich hantiere schon jahrelang mit Linux (5 Rechner) und mit Festplatten noch viel länger... zugegeben, zu lernen gibt es immer viel und manchmal sitze ich auch auf dem Schlauch.
Habe es ja an zwei Rechner versucht um Hardwarefehler auszuschließen!
Und mit USB ging es garnicht (siehe seite 1 oder 2).
Bei gdisk stimmt einiges nicht!!! Habe ein paar Versuche die letzten Tage unternommen, jetzt wo mein Puls wieder ruhiger schlägt.
- erstens widersprachen sich die Fehlermeldungen bei mir
- zweitens, habe ich versucht eine nun blanke Disk mit gdisk zu partitionieren, ging gut, aber ein einziuger Zugriff mit tune2fs und der gpt ist laut gdisk weg. Die platte lässt sich aber nach wie vor normal mounten
- erstelle ich eine gpt Partition mit parted und öffne ich diese dann mit gdisk mit dem Befehl gdisk /dev/sdx dann ist lauf Bildschirmausgabe kein gpt und kein mbr vorhanden. Mache ich ein verify oder prüfe ich mit gdsik -l /dev(sdx ist alles okay, gpt und mbr vorhanden.
- eine mit parted oder gparted erstellte Partition hat laut gdisk in der Regel eine größere Größe als die Festplatte hergibt. Ein schreiben mit gdisk ist auf solchen Platten dann nicht mehr möglich....
usw...
Ich werde erstmal die Finger von gdisk lassen! Parted scheint das ausgereiftere Tool für gpt und Platte >2TByte zu sein.
Für alle, die die Wahl haben ob mbr oder gpt (also <2Tbyte), rate ich derzeit zu mbr!