lvm-Partition nicht mountbar

[mc_gulasch]

Hi zusammen,

ich hab meine Partitionen mit dem Logical-Volume-Manager (lvm) verwaltet. Warum auch immer hat´s mir eine Festplatte (/dev/hdb1) zerschossen, heisst sie war einfach weg...also die logische Partition. Gut, die Daten sind auf der /dev/hdb noch drauf, aber ich komm nicht dran.

Ich hab erst nochmal eine Primäre Partition hdb1 erstellt. Ging wunderbar. Aber mounten ging nicht, da ich über

pvcreate /dev/hdb1

eine lvm-spezifische pysikalische Festplatte angelegt hab:

lvmdiskscan
  /dev/ram0  [       62.50 MB]
  /dev/dm-0  [      372.00 GB]
  /dev/ram1  [       62.50 MB]
  /dev/hda1  [       20.00 GB]
  /dev/sda1  [      279.46 GB]
  /dev/ram2  [       62.50 MB]
  /dev/hda2  [       25.00 GB]
  /dev/ram3  [       62.50 MB]
  /dev/hda3  [        2.01 GB]
  /dev/ram4  [       62.50 MB]
  /dev/hda4  [        8.89 GB]
  /dev/ram5  [       62.50 MB]
  /dev/ram6  [       62.50 MB]
  /dev/ram7  [       62.50 MB]
  /dev/ram8  [       62.50 MB]
  /dev/ram9  [       62.50 MB]
  /dev/ram10 [       62.50 MB]
  /dev/ram11 [       62.50 MB]
  /dev/ram12 [       62.50 MB]
  /dev/ram13 [       62.50 MB]
  /dev/ram14 [       62.50 MB]
  /dev/ram15 [       62.50 MB]
  /dev/hdb1  [      372.61 GB] LVM physical volume
  0 disks
  22 partitions
  0 LVM physical volume whole disks
  1 LVM physical volume

Daher erzählt mir dann mount:

mount /dev/hdb1 /daten
mount: unknown filesystem type 'LVM2_member'

Also wollte ich nochmal das alte lvm-System herstellen:

Ich habe mich (und tu´s noch immer) bei der Erstellung an dieses Tutorial gehalten:

Tutorial

wenn ich nach diesem vorgehe, funktioniert alles wunderbar bis

mount -t ext3 /dev/daten/daten /daten
mount: wrong fs type, bad option, bad superblock on /dev/daten/daten,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Aha, ok, also falscher Datentyp...gut, also schau ich nach:

fdisk -l

Disk /dev/hda: 60.0 GB, 60022480896 bytes
255 heads, 63 sectors/track, 7297 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1               1        2611    20972826    7  HPFS/NTFS
/dev/hda2   *        2612        5875    26218080   83  Linux
/dev/hda3            5876        6137     2104515   82  Linux swap / Solaris
/dev/hda4            6138        7297     9317700    c  W95 FAT32 (LBA)

Disk /dev/hdb: 400.0 GB, 400088457216 bytes
255 heads, 63 sectors/track, 48641 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hdb1               1       48641   390708801   83  Linux

Disk /dev/sda: 300.0 GB, 300069052416 bytes
255 heads, 63 sectors/track, 36481 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1       36481   293033601   83  Linux

Disk /dev/dm-0: 399.4 GB, 399431958528 bytes
255 heads, 63 sectors/track, 48561 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/dm-0 doesn't contain a valid partition table

Aber irgendwas scheint ja nicht zu stimmen, da /dev/dm-0 wohl nicht die passende Partitionstabelle hat. Ok, die stimmt also nicht. Gut. Schließlich ist ja /dev/hdb1 auch eigentlich doch LVM, also ID 8e, aber hier wird 83 gesagt. Das hat mich schon mal verwirrt.

Auch dieser Versuch hat mich nicht weitergebracht.

Also hab ich mir "testdisk" geholt, welches mir folgende Ausgabe liefert:

Disk /dev/hdb - 400 GB / 372 GiB - CHS 48641 255 63
     Partition               Start        End    Size in sectors
P Linux LVM                0   1  1 48640 254 63  781417602

also auch wieder LVM. Ich hab jetzt wie hier unter Punkt 4 beschrieben weitergemacht.
Ich hab jetzt also die Möglichkeit nen neuen Partitionstyp anzulegen. Aber fdisk -l sagt mir ich hätte 83 und testdisk sagt mir ich hätte 8e.

1. FRAGE:
Wie finde ich bitte raus, welchen Partitionstyp ich jetzt tatsächlich habe

2, FRAGE:
Kann ich, nachdem ja hdb1 bereits fest über o.g. pvcreate fest lvm zugewiesen wurde, überhaupt den Partitionstyp ändern?

Die Daten, die auf der Platte sind, wurden auch schon auf die Platte im lvm draufgespielt (falls das wichtig ist). Ich kann leider die Platte auch nicht einfach aus dem LVM löschen, da: Guckst du (-> 3.3. -> Volumes vergrößern / -kleinern)



Also entweder bring ich die Platte wieder in den lvm oder ich schaff es, dass ich sie wieder aus der lvm-Abhängigkeit löse und woanders verlustfrei mounte. Kann mir da irgendwer helfen Bin schon am Rand der Verzweiflung, will meine Daten!

 

[Dennis Wronka]

Also so genau weiss ich das jetzt auch nicht alles, aber ich will trotzdem mal ein wenig spekulieren.

Du hast also, aus Dir unbekannten Gruenden Deine Partition verloren, richtig?
Und per fdisk/parted oder einem aehnlichen Programm hast Du diese wieder angelegt und dann per pvcreate zu einem Physical Volume gemacht, richtig?

Bevor es jetzt weiter geht mal zwei Fragen:
War diese Partition allein in der VolumeGroup oder gab es noch andere Physical Volumes darin?
Gab es in der Volume Group nur ein Logical Volume oder mehrere?

Okay, weiter im Text. Ich nehme jetzt einfach mal an dass Deine VG aus nur einem PV bestand und nur ein LV beherbergt hat, denn alles andere duerfte nur sehr schwer bis unmoeglich wieder herstellbar sein, wenn sich denn ueberhaupt schon bei der jetzt angenommenen Konfiguration was machen laesst.

Du hast also die Partition wieder erstellt, was erstmal nicht schlimm ist da der Datenbereich dabei ja nicht angefasst wird. Trotzdem duerfte aber der Partitionskopf leer sein.
Diesen hast Du dann aber mittels pvcreate so umgemodelt dass LVM weiss dass es sich um ein Physical Volume handelt.
Dies hat einen neuen Kopf fuer das PV angelegt, welcher natuerlich auch keine Daten mehr hat ueber irgendwelche eventuell zuvor existenten VGs oder LVs.
Und ich nehme auch mal an, dass Du auch VG und LV wieder erstellt hast, was nun fuer das Logical Volume bedeutet dass es existiert und wahrscheinlich auch physikalisch den Platz einnimmt den es auch zuvor genutzt hat.
Jetzt stehst Du aber weiterhin vor dem Problem dass Dein Volume kein Dateisystem hat, zumindest weiss es das nicht.
Und jetzt kommt das eigentliche Problem, denn es gibt, meiner Meinung nach, keinen Weg das Dateisystem einzurichten, also den Superblock zu schreiben ohne die, eventuell sowieso schon beschaedigte oder gar geloeschte/ueberschriebene, Inode-Tabelle neu anzulegen. Wenn Du also ein Dateisystem anlegst wird dieses leer sein. Physikalisch sind die Daten dann (wahrscheinlich, wenn nicht grundlegend was mit der Platte nicht okay ist) zwar immer noch da, nur kommst Du weiterhin nicht dran.

Moeglicherweise laesst sich mit dd noch was retten, aber das wird auch nicht einfach werden.

Zur vorher angesprochenen Konfiguration mit mehreren PVs und/oder LVs: Da dann die Daten quasi wild verteilt sind, vor allem wenn Du mehrere PVs hattest macht das die ganze Sache nicht einfacher.

 

[mc_gulasch]

Na du machst mir Mut. Gut, zu den offenen Fragen:

Und per fdisk/parted oder einem aehnlichen Programm hast Du diese wieder angelegt und dann per pvcreate zu einem Physical Volume gemacht

Ich nutze SUSE 10.2 und hab´s über Yast gemacht. Meines wissen is das die GUI vom gpart

War diese Partition allein in der VolumeGroup oder gab es noch andere Physical Volumes darin?
Gab es in der Volume Group nur ein Logical Volume oder mehrere?

War jeweils die einzige

Und ich nehme auch mal an, dass Du auch VG und LV wieder erstellt hast

Genau

Wenn die Platte im LVM eingebunden ist, wird mir angezeigt, dass sie voll ist. Auch das Kauderwelsch aus ID 83, 8e, LVM, nicht LVM, mal erkannt mal nicht entzieht sich völlig meinem Feaschdändnis!

Bei "testdisk" ist das Programm "photoresc*" dabei. Ich hab´s mal auf die Platte angewandt und es stellt auch einige Sachen wieder her, allerdings *.vob Dateien als mpg, unerkennbare Dateien als .txt, usw. ganz abgesehen von der nicht mehr nachvollziehbaren Namensgebung der Daten. Wahrscheinlich könnten also Recovery-Programme was bringen, wobei ich schon gerne genau die Daten wieder hergestellt haben möcht, die da auch drauf sind (inkl. Namensgebung). Der Aufwand das wieder händisch zu reparieren ist mir bei vollen 400 GB verständlicherweise zu groß.

Erhält dd die Namensgebung? Ich weiß nur, dass das Programm bitweise kopiert. Das hieße aber auch, dass ich wohl zum kopieren ne andere 400GB Platte bräuchte?
Danke für deine Mühen!

//EDIT:

* ich weiß, dass es ein Programm vornehmlich zum Wiederherstellen von Bilddateien ist. Aber ich wollt halt mal wissen, ob überhaupt was passiert und ob überhaupt was wiederhergestellt wird.

//EDIT2:

Hab das Thema jetzt hier auch nochmal gepostet.

 

[mc_gulasch]

Ich bin jetzt auch noch auf pvmove gestoßen. Hat jemand Erfahrung damit gemacht?
Abgeschmiert ist mir die 400 GB Platte. Ziel ist es also mind. weitere 400 GB in den lvm einzubinden um dann das Zeug zu moven.

In der Beschreibung zu pvmove steht

pvmove allows you to move the allocated physical extents (PEs) on SourcePhysicalVolume to one or more other physical volumes (PVs).

Was genau sind "pysical extents"?