[DE] Was stimmt da nicht? 3TB Platten werden nicht mehr gemountet

[Lanzi]

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:

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...?

[agaida]

lanzi, im Forum hast Du gestern einen Link bekommen, die Settings, die in dem Link angegeben waren, würde ich mal prüfen.

[Lanzi]

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!

[agaida]

[Saturday, January 14, 2012] [12:45:14 AM] <premix_> Lanzi2: sieh mal hier: http://www.pjc.me.uk/efi-gpt/index.html

[bluelupo]

Hi Lanzi,
wenn du mit GPT hantierst würde ich statt fdisk, dir gdisk wärmstens an's Herz legen.

Code: [Select]


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.


[Lanzi]

@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.

[jure]

man gdisk

gdisk - Interactive GUID partition table (GPT) manipulator

SYNOPSIS
       gdisk [ -l ] device
.....

[agaida]

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:

Code: [Select]


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.

[Lanzi]

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

mount /dev/sdb1/ /mnt/sdb1
mount: special device /dev/sdb1/ does not exist

fdsik -l

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

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

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

Zu guter Letzt die Ausgabe von gdisk - welche einen Hinweis gibt

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?

[unklarer]

Hi Lanzi,

in Deinem ssd-Thread schreibst Du

...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.

Mit 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

[Lanzi]

@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?

[unklarer]

Ja, und Du hast Dir keinen Virus etc. eingefangen.

MBR-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:

[unklarer]

oder übersehe ich da was?

bzw. Partitionen > 2 TB anlegen und verwalten zu können.

[Lanzi]

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?

[unklarer]

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  

Code: [Select]

gdiskund später weiter unten von der herkömmlichen... mit Hilfe von

Code: [Select]

fdisk

m.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...