Sign in to follow this  
Chavelle

Keine LVM informationen - VG Informationen nicht verfügbar

Recommended Posts

Hi Leute ich versuche es auch hier noch mal im deutschen Bereich, vielleicht hat ja jemand hier Hilfe für mich.

Ich habe ein Problem mit meinem Xpenology-System, dass der LVM nicht mehr sauber online kommt

 

Kurze Beschreibung des Setups.

Mein Xpenology-Systen läuft auf DSM 5.2 Build 5644 als Hyper-V VM mit einem Raid-5 und 5 Daten Disks.

Die Disks sind via Passthrough der VM zugewiesen, daher kann ich auch keine Snapshots nutzen.

 

Eine kurze Beschreibung wie es zu dem Problem gekommen ist. Nach einem Stromausfall hat DSM versucht eine Daten Konsistenzprüfung durchzuführen. Während dieser Prüfung kam es zu Disk-Fehlern so dass diese Disks vom LVM als Fehlerhaft markiert wurden. Danach waren also nur noch 3 der 5 Disks aktiv und das Raid damit Fehlerhaft.

 

Ich habe gehofft über einen DSM reboot könnte der LVM wieder neu aufgebaut werden, dem war aber nicht so.

Nach ein bisschen google'n um eine entsprechende Lösung zu finden, habe ich mich entschieden das Raid neu aufzubauen, da dabei entsprechend bekannte Raid-Infos wohl entsprechend gelesen werden könnten.

 

Nachdem der LVM neu aufgebaut wurde, war ich aber immer noch nicht in der Lage die Volumes zu sehen. Allerdings entspricht die nun angezeigte "Used size" durchaus der zuletzt bekannten Auslastung.

 

Ich habe mal einige, vielleicht nützliche, Informationen gesammelt und packe diese hier mit rein.

 

Current LVM status:

mdadm --detail /dev/md2
/dev/md2:
       Version : 1.2
 Creation Time : Sun Apr 23 11:25:47 2017
    Raid Level : raid5
    Array Size : 7551430656 (7201.61 GiB 7732.66 GB)
 Used Dev Size : 1887857664 (1800.40 GiB 1933.17 GB)
  Raid Devices : 5
 Total Devices : 5
   Persistence : Superblock is persistent

   Update Time : Tue Apr 25 19:42:26 2017
         State : clean
Active Devices : 5
Working Devices : 5
Failed Devices : 0
 Spare Devices : 0

        Layout : left-symmetric
    Chunk Size : 64K

          Name : vmstation:2  (local to host vmstation)
          UUID : fa906565:71190489:ea521509:a7999784
        Events : 2

   Number   Major   Minor   RaidDevice State
      0       8       67        0      active sync   /dev/sde3
      1       8       83        1      active sync   /dev/sdf3
      2       8      115        2      active sync   /dev/sdh3
      3       8       35        3      active sync   /dev/sdc3
      4       8       51        4      active sync   /dev/sdd3

 

"vgchange -ay" - no output

"pvs" - no output

"lvdisplay" - no output

"lvscan" - no output

"vgscan" - no output

"vgs" - no output

 

I have something from /etc/lvm/archive/

 

vmstation> cat vg1_00004.vg
# Generated by LVM2 version 2.02.38 (2008-06-11): Mon Mar  6 07:59:38 2017

contents = "Text Format Volume Group"
version = 1

description = "Created *before* executing '/sbin/lvextend --alloc inherit /dev/vg1/volume_1 --size 6289408M'"

creation_host = "vmstation"     # Linux vmstation 3.10.35 #1 SMP Tue Feb 2 17:44:24 CET 2016 x86_64
creation_time = 1488783578      # Mon Mar  6 07:59:38 2017

vg1 {
       id = "V7LhPs-YK34-rCUy-TAE9-eNJP-5t9M-exZx3C"
       seqno = 11
       status = ["RESIZEABLE", "READ", "WRITE"]
       extent_size = 8192              # 4 Megabytes
       max_lv = 0
       max_pv = 0

       physical_volumes {

               pv0 {
                       id = "DKv9e6-mh0q-6SZ5-VNS6-bXHw-hSkL-wFPFSK"
                       device = "/dev/md2"     # Hint only

                       status = ["ALLOCATABLE"]
                       dev_size = 15102858624  # 7.03282 Terabytes
                       pe_start = 1152
                       pe_count = 1843610      # 7.03281 Terabytes
               }
       }

       logical_volumes {

               syno_vg_reserved_area {
                       id = "Uc1Q6V-f2vY-xKLI-kH0n-OS1f-6P6Q-fWQD5I"
                       status = ["READ", "WRITE", "VISIBLE"]
                       segment_count = 1

                       segment1 {
                               start_extent = 0
                               extent_count = 3        # 12 Megabytes

                               type = "striped"
                               stripe_count = 1        # linear

                               stripes = [
                                       "pv0", 0
                               ]
                       }
               }

               volume_1 {
                       id = "6WOtW4-g3mq-796S-sAcm-bqpI-HUzk-OOE3Kc"
                       status = ["READ", "WRITE", "VISIBLE"]
                       segment_count = 2

                       segment1 {
                               start_extent = 0
                               extent_count = 1281280  # 4.8877 Terabytes

                               type = "striped"
                               stripe_count = 1        # linear

                               stripes = [
                                       "pv0", 3
                               ]
                       }
                       segment2 {
                               start_extent = 1281280
                               extent_count = 118528   # 463 Gigabytes

                               type = "striped"
                               stripe_count = 1        # linear

                               stripes = [
                                       "pv0", 1290243
                               ]
                       }
               }

               iscsi_0 {
                       id = "MoikYK-1lu2-qV2L-VsH8-FreO-W01t-htNHt8"
                       status = ["READ", "WRITE", "VISIBLE"]
                       segment_count = 1

                       segment1 {
                               start_extent = 0
                               extent_count = 3840     # 15 Gigabytes

                               type = "striped"
                               stripe_count = 1        # linear

                               stripes = [
                                       "pv0", 1281283
                               ]
                       }
               }

               iscsi_1 {
                       id = "VOl2iq-NFNs-eNXv-uCi5-BmC1-al9s-88f8eg"
                       status = ["READ", "WRITE", "VISIBLE"]
                       segment_count = 1

                       segment1 {
                               start_extent = 0
                               extent_count = 5120     # 20 Gigabytes

                               type = "striped"
                               stripe_count = 1        # linear

                               stripes = [
                                       "pv0", 1285123
                               ]
                       }
               }
       }
}

 

cat /etc/fstab
none /proc proc defaults 0 0
/dev/root / ext4 defaults 1 1

 

e2fsck /dev/md2
Bad magic number in super-block while trying to open /dev/md2

 

Das war soweit alles...

 

Ich hoffe jemand von euch kann mir helfen.

 

Danke euch.

 

Gruß

Thomas

Share this post


Link to post
Share on other sites

Eine kurze Beschreibung wie es zu dem Problem gekommen ist. Nach einem Stromausfall hat DSM versucht eine Daten Konsistenzprüfung durchzuführen. Während dieser Prüfung kam es zu Disk-Fehlern so dass diese Disks vom LVM als Fehlerhaft markiert wurden. Danach waren also nur noch 3 der 5 Disks aktiv und das Raid damit Fehlerhaft.

 

ich vermute du bist hier irgendiwe uaf dem falschen dampfer was LVM angeht

ein synology software raid ist im grunde "nur" mdadm (fürs raid) und LVM für das volume (aber nur wenn man auf einem RAID aka Raidgroup mehrere Volumes haben will - so kann man den platz auf dem RAID beleibig zwischen den volumes darauf verteilen)

man bekomme durch mdadm ein "großes" devive /dev/md2 das dann als solches von LVM benutzt wird, LVM weis im grunde garnichts von den raid darunter, für den ist das nur eine große disk auf der man was anlegen kann

wenn man im diskmanager ein RAID5/6 anlegt beim anlegen des volumes auf der raidgroup angibt das man nur ein Volume haben will dann wird gar kein LVM benutzt dann hat man "reines" mdadm (/dev/md2) das dann mit fdisk partitioniert wird und dann formatiert wird (btrfs oder ext4)

wenn also "disks" weg gewesen sind dann ist das nicht LVM sondern hat was mit mdadm zu tun und wenn das /dev/md2 deshlab nicht zur verfügung steht dann gibts auch nichts für lvm zu tun

 

 

Ich habe gehofft über einen DSM reboot könnte der LVM wieder neu aufgebaut werden, dem war aber nicht so.

Nach ein bisschen google'n um eine entsprechende Lösung zu finden, habe ich mich entschieden das Raid neu aufzubauen, da dabei entsprechend bekannte Raid-Infos wohl entsprechend gelesen werden könnten.

 

Nachdem der LVM neu aufgebaut wurde, war ich aber immer noch nicht in der Lage die Volumes zu sehen. Allerdings entspricht die nun angezeigte "Used size" durchaus der zuletzt bekannten Auslastung.

 

wie hast du bei 2 fehlerhaften platten und raid5 (1 platte redudanz) wieder ein laufendes raid5 bekommen, das kann erst mal so ohne weiteres nicht gehen wenn die zwei platten defekt/weg sind

hier fehlt mir irgenwie etwas, ohne das wenigstens eine der "fehlende" platten wieder voll funktionsfähig auftaucht kann man das raid nicht wieder in betireb nehmen und nach den sachen weiter unten hast du 5 funktionierende lufwerke im raid, da kommen man nicht von 3 wieder auf 5 ohne das entweder die zwei platten wieder (unbeschädigt) da sind oder man das raid komplett neu anlegt (in letzterem fall kann es natürlich keine LVM mehr geben denn das /dev/md2 ist dann ein komlett neues/leeres device)

 

 

Ich habe mal einige, vielleicht nützliche, Informationen gesammelt und packe diese hier mit rein.

 

Current LVM status:

mdadm --detail /dev/md2
/dev/md2:
       Version : 1.2
 Creation Time : Sun Apr 23 11:25:47 2017
    Raid Level : raid5
    Array Size : 7551430656 (7201.61 GiB 7732.66 GB)
 Used Dev Size : 1887857664 (1800.40 GiB 1933.17 GB)
  Raid Devices : 5
 Total Devices : 5
   Persistence : Superblock is persistent

   Update Time : Tue Apr 25 19:42:26 2017
         State : clean
Active Devices : 5
Working Devices : 5
Failed Devices : 0
 Spare Devices : 0

        Layout : left-symmetric
    Chunk Size : 64K

          Name : vmstation:2  (local to host vmstation)
          UUID : fa906565:71190489:ea521509:a7999784
        Events : 2

   Number   Major   Minor   RaidDevice State
      0       8       67        0      active sync   /dev/sde3
      1       8       83        1      active sync   /dev/sdf3
      2       8      115        2      active sync   /dev/sdh3
      3       8       35        3      active sync   /dev/sdc3
      4       8       51        4      active sync   /dev/sdd3

 

das sieht soweit nach einen funktionsfähigen raid5 aus 5 platten aus, einzige auffäligkeit ist das es kein sda und sdb gibt

außerdem ist die creation time 23.04.2017 aber zeimlich dicht am "jetzt" - also doch neu angelegt?

und wenn ich mir die creation time des lvm aud der archive datei ansehe - 06.03.207 dann passt das auch nicht, das lvm kann nicht vor dem raid angelgt sein, erst erzeugt man das raid und oben drauf kommt lvm

ansonten sieht man auch sehr schön am dem archive zeug das das lvm nicht aus "disks" bestand sondern aus /dev/md2 (nur ein physical device pv0)

du hattest da drin 4 logigal volumes, eins das von synology zur reserve angelegt wurde, das normale "volume1" (das aber aus 2 segmenten besteht - mal irgendwas um-/aufgerüstet oder SHR mit sda/sdb?)

und zwei iSCSI volumes zu je 15GB und 20GB - soviel kann man da zumindest rauslesen

aber wenn in dem funktionierenden /dev/md2 keine LVM mehr zu finden ist und es wirklich noch das "alte" (richtige ist - was ich je bezweifle) dann würde nur richtiges datarecovery mit low level tools helfen, man müsste mit einem sektoreditor in /dev/md2 nach spuren der LVM Volumes suchen und sie mit den ihhalten der archive datei vergleichen

evtl. kann man auch mit irgendwelchen kommendos die alte lvm archive datei dem /dev/md2 "aufzwingen" aber das würde die daten auf dem volume verändern und weites recovery erschweren/verhindern (da man daten verändert) - aber wenn man sonst das ganze wegwerfen würde kann man das zumindest als letztes mittel vor dem abfalleimer machen und sehen was passiert - allerdings habe ich da nichts parat, das habe ich noch nie gemacht, ist nur rein theoretisch was man machen könnte (bzw. was ich versuchen würde)

 

man kann auch den ihalt von /dev/md2 "sichern" mit dd aber da bräuchte man eine 6TB platte, viel zeit um sich mit data recovery zu beschäftigen, ... das wird man nur machen wenn es kein backup gibt und die daten echt wichtig sind (bzw. kann man so eine mit dd erstellte kopie vermutlich auch datenrettungsprofis geben aber sowas ist in der regel für privat zu teuer)

 

ich bin mir zwar nicht ganz sicher aber - mein beileid zum verlust der daten

Share this post


Link to post
Share on other sites

Habe das gleiche wie du. Nur habe ich eine Platte.

Nachdem ich

mdadm --assemble --force -v /dev/md2 /dev/sda3

war das volume wieder da und mit dem Eintrag in der fstab konnte ich es auch wieder unter /volume1 mounten und alle daten waren da.

 

Jedoch nach jedem Reboot war alles wieder weg, Was kann ich machen?

Aufgefallen war es mir, als der DSM nicht mehr erreichbar war. Hatte da die Synology Fehlermeldung von wegen es ist was schief gelaufen. Also ähnlich dem Time Bomb Problem.

 

 

Share this post


Link to post
Share on other sites
16 hours ago, sze said:

Habe das gleiche wie du. Nur habe ich eine Platte.

Nachdem ich

mdadm --assemble --force -v /dev/md2 /dev/sda3

war das volume wieder da und mit dem Eintrag in der fstab konnte ich es auch wieder unter /volume1 mounten und alle daten waren da.

 

Jedoch nach jedem Reboot war alles wieder weg, Was kann ich machen?

Aufgefallen war es mir, als der DSM nicht mehr erreichbar war. Hatte da die Synology Fehlermeldung von wegen es ist was schief gelaufen. Also ähnlich dem Time Bomb Problem.

 

 

ich habe kaum praktische erfahrung mit der reparatur von linux dateisystemen und raids (so viel linux umgang habe ich nicht und da kam das bisher kaum vor, waren wenn eher defekte sektoren auf einfachen platten ohne lvm und mdadm oder trockenübungen)

 

aber mal so aus der theorie wie das funktioniert heraus

wenn man aus einem raid platten entfernt und sie mit "force" wieder "reinzwingt" dann muss man mit inkonsistenz rechnen (raid prüfsummen die "vealtet" sind weil daten geschrieben wurden aber ohne die prüfsumme) und sollte wohl die prüfsummen neu erzeugen/überprüfen so das alle sektoren der platten auch eine passende prüfsumme haben und natürlich sollte man das in dem raid liegende dateisystem auf konsistenz prüfen bzw. reparieren - gibt ja einen grund warum ein mdadm raid nicht automatisch beim "zusammengesetzt" wird beim boot bzw. ein dateisystem nicht gemountet wird und diese günde muss man beseitigen, es gibt für sowas in der regel auch dirty flags und die werden bei einer überprüfung, neu berechnung der prüfsummen dann auch zurückgesetzt

 

da sowohl mdadm als auch ext4/btrfs standard linux sachen sind findet man dazu auch jede menge infos und howto's im netz, ist nichts was sysnology erfunden hat und nur für dsm gilt

 

Edited by IG-88

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this