[gentoo-user-ru] LVM: incorrect metadata area header checksum

[gentoo-user-ru] LVM: incorrect metadata area header checksum

[Konstantin]

Hello Gentoo-user-ru,

Пробовал сегодня на файловом сервере обновить ядро до
sys-kernel/hardened-sources-2.6.36-r6 и после перезагрузки обнаружил
что при загрузке системы (RAID-6 из шести дисков - /dev/md2, на нем
содан LVM "vg" рут находится на /dev/vg/slash) lvm не может обнаружить
logical volumes:

Incorrect metadata area header checksum
Incorrect metadata area header checksum
Incorrect metadata area header checksum
Volume group "vg" inconsistent
Incorrect metadata area header checksum
Incorrect metadata area header checksum
WARNING: Inconsistent metadata found for VG vg - updating to use version 29
Incorrect metadata area header checksum
Automatic metadata correction failed

Крайне не хочется терять данные, поэтому хочу спросить совета у тех
кто когда-нибудь сталкивался с такой проблемой.

-- 
Konstantin

Re: [gentoo-user-ru] LVM: incorrect metadata area header checksum

[Konstantin]

Приветствую!

Sunday, January 2, 2011, 21:39:39, Konstantin wrote:
> Пробовал сегодня на файловом сервере обновить ядро до
> sys-kernel/hardened-sources-2.6.36-r6 и после перезагрузки обнаружил
> что при загрузке системы (RAID-6 из шести дисков - /dev/md2, на нем
> содан LVM "vg" рут находится на /dev/vg/slash) lvm не может обнаружить
> logical volumes:

> Incorrect metadata area header checksum
> Incorrect metadata area header checksum
> Incorrect metadata area header checksum
> Volume group "vg" inconsistent
> Incorrect metadata area header checksum
> Incorrect metadata area header checksum
> WARNING: Inconsistent metadata found for VG vg - updating to use version 29
> Incorrect metadata area header checksum
> Automatic metadata correction failed

> Крайне не хочется терять данные, поэтому хочу спросить совета у тех
> кто когда-нибудь сталкивался с такой проблемой.

Уже несколько часов безуспешно пытаюсь восстановить данные. :(

C livecd видно, что RAID работает исправно:

livecd ~ # cat /proc/mdstat
Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md126 : active raid6 sdf2[4] sda2[0] sdc2[2] sdd2[5] sdb2[1] sde2[3]
      3906525696 blocks level 6, 64k chunk, algorithm 2 [6/6] [UUUUUU]

md127 : active (auto-read-only) raid1 sde1[4] sdd1[3] sdf1[5] sda1[0] sdb1[1] sdc1[2]
      128384 blocks [6/6] [UUUUUU]

unused devices: <none>

Память на всякий случай протестировал - memtest86 в течении двух
часов ошибок не нашел. Пытаюсь разобраться как можно восстановить LVM,
но не хватает теоретических знаний.

livecd ~ # pvck /dev/md126 -vvv
        Processing: pvck /dev/md126 -vvv
        O_DIRECT will be used
      Setting global/locking_type to 1
      Setting global/wait_for_locks to 1
      File-based locking selected.
      Setting global/locking_dir to /var/lock/lvm
    Scanning /dev/md126
        Opened /dev/md126 RO O_DIRECT
        /dev/md126: block size is 4096 bytes
      /dev/md126: lvm2 label detected
        lvmcache: /dev/md126: now in VG #orphans_lvm2 (#orphans_lvm2)
        /dev/md126: Found metadata at 77824 size 3129 (in area at 4096 size 192512) for vg (RyQ0r4-vERQ-gSum-35Fo-EL08-LcBI-VauxJ5)
        lvmcache: /dev/md126: now in VG vg with 2 mdas
        lvmcache: /dev/md126: setting vg VGID to RyQ0r4vERQgSum35FoEL08LcBIVauxJ5
        lvmcache: /dev/md126: VG vg: Set creation host to ftp.
  Incorrect metadata area header checksum on /dev/md126 at offset 3000211603456
        Closed /dev/md126
  Found label on /dev/md126, sector 1, type=LVM2 001
  Found text metadata area: offset=4096, size=192512
        Opened /dev/md126 RO O_DIRECT
        /dev/md126: block size is 4096 bytes
    Found LVM2 metadata record at offset=74752, size=3072, offset2=0 size2=0
    Found LVM2 metadata record at offset=71680, size=3072, offset2=0 size2=0
    Found LVM2 metadata record at offset=68608, size=3072, offset2=0 size2=0
    Found LVM2 metadata record at offset=65536, size=3072, offset2=0 size2=0
    Found LVM2 metadata record at offset=62464, size=3072, offset2=0 size2=0
    Found LVM2 metadata record at offset=58880, size=3584, offset2=0 size2=0
    Found LVM2 metadata record at offset=53760, size=5120, offset2=0 size2=0
    Found LVM2 metadata record at offset=48640, size=5120, offset2=0 size2=0
    Found LVM2 metadata record at offset=43520, size=5120, offset2=0 size2=0
    Found LVM2 metadata record at offset=38400, size=5120, offset2=0 size2=0
    Found LVM2 metadata record at offset=33280, size=5120, offset2=0 size2=0
    Found LVM2 metadata record at offset=28160, size=5120, offset2=0 size2=0
    Found LVM2 metadata record at offset=23040, size=5120, offset2=0 size2=0
    Found LVM2 metadata record at offset=17920, size=5120, offset2=0 size2=0
    Found LVM2 metadata record at offset=12800, size=5120, offset2=0 size2=0
    Found LVM2 metadata record at offset=7680, size=5120, offset2=0 size2=0
        Closed /dev/md126
  Found text metadata area: offset=3000211603456, size=131072
        Opened /dev/md126 RO O_DIRECT
        /dev/md126: block size is 4096 bytes
  Incorrect metadata area header checksum on /dev/md126 at offset 3000211603456
        Closed /dev/md126

Вижу что сами логические разделы на каком-то уровне видны:

livecd ~ # vgdisplay -vvv
        Processing: vgdisplay -vvv
        O_DIRECT will be used
      Setting global/locking_type to 1
      Setting global/wait_for_locks to 1
      File-based locking selected.
      Setting global/locking_dir to /var/lock/lvm
    Finding all volume groups
      /dev/md126: lvm2 label detected
        lvmcache: /dev/md126: now in VG #orphans_lvm2 (#orphans_lvm2)
        /dev/md126: Found metadata at 77824 size 3129 (in area at 4096 size 192512) for vg (RyQ0r4-vERQ-gSum-35Fo-EL08-LcBI-VauxJ5)
        lvmcache: /dev/md126: now in VG vg with 2 mdas
        lvmcache: /dev/md126: setting vg VGID to RyQ0r4vERQgSum35FoEL08LcBIVauxJ5
        lvmcache: /dev/md126: VG vg: Set creation host to ftp.
  Incorrect metadata area header checksum on /dev/md126 at offset 3000211603456
        Closed /dev/md126
        Opened /dev/md127 RO O_DIRECT
        /dev/md127: block size is 4096 bytes
      /dev/md127: No label detected
        Closed /dev/md127
    Finding volume group "vg"
      Locking /var/lock/lvm/V_vg RB
        _do_flock /var/lock/lvm/V_vg:aux WB
        _undo_flock /var/lock/lvm/V_vg:aux
        _do_flock /var/lock/lvm/V_vg RB
        Opened /dev/md126 RO O_DIRECT
        /dev/md126: block size is 4096 bytes
      /dev/md126: lvm2 label detected
        lvmcache: /dev/md126: now in VG #orphans_lvm2 (#orphans_lvm2) with 2 mdas
        /dev/md126: Found metadata at 77824 size 3129 (in area at 4096 size 192512) for vg (RyQ0r4-vERQ-gSum-35Fo-EL08-LcBI-VauxJ5)
        lvmcache: /dev/md126: now in VG vg with 2 mdas
        lvmcache: /dev/md126: setting vg VGID to RyQ0r4vERQgSum35FoEL08LcBIVauxJ5
        lvmcache: /dev/md126: VG vg: Set creation host to ftp.
  Incorrect metadata area header checksum on /dev/md126 at offset 3000211603456
        Using cached label for /dev/md126
        Read vg metadata (29) from /dev/md126 at 77824 size 3129
  Incorrect metadata area header checksum on /dev/md126 at offset 3000211603456
        /dev/md126 0:      0   2560: slash(0:0)
        /dev/md126 1:   2560   1024: log(0:0)
        /dev/md126 2:   3584    512: portage(0:0)
        /dev/md126 3:   4096   1024: distfiles(0:0)
        /dev/md126 4:   5120    512: tmp(0:0)
        /dev/md126 5:   5632    256: mysql(0:0)
        /dev/md126 6:   5888    256: home(0:0)
        /dev/md126 7:   6144 524288: ftp(0:0)
        /dev/md126 8: 530432   2048: swap(0:0)
        /dev/md126 9: 532480 390144: ftp(524288:0)
        /dev/md126 10: 922624   2304: mysql(256:0)
        /dev/md126 11: 924928  28813: NULL(0:0)
      Unlocking /var/lock/lvm/V_vg
        _undo_flock /var/lock/lvm/V_vg
        Closed /dev/md126
      Locking /var/lock/lvm/V_vg WB
        _do_flock /var/lock/lvm/V_vg:aux WB
        _do_flock /var/lock/lvm/V_vg WB
        _undo_flock /var/lock/lvm/V_vg:aux
        Opened /dev/md126 RW O_DIRECT
        /dev/md126: block size is 4096 bytes
      /dev/md126: lvm2 label detected
        lvmcache: /dev/md126: now in VG #orphans_lvm2 (#orphans_lvm2) with 2 mdas
        /dev/md126: Found metadata at 77824 size 3129 (in area at 4096 size 192512) for vg (RyQ0r4-vERQ-gSum-35Fo-EL08-LcBI-VauxJ5)
        lvmcache: /dev/md126: now in VG vg with 2 mdas
        lvmcache: /dev/md126: setting vg VGID to RyQ0r4vERQgSum35FoEL08LcBIVauxJ5
        lvmcache: /dev/md126: VG vg: Set creation host to ftp.
  Incorrect metadata area header checksum on /dev/md126 at offset 3000211603456
        Using cached label for /dev/md126
        Read vg metadata (29) from /dev/md126 at 77824 size 3129
  Incorrect metadata area header checksum on /dev/md126 at offset 3000211603456
  WARNING: Inconsistent metadata found for VG vg - updating to use version 29
        /dev/md126 0:      0   2560: slash(0:0)
        /dev/md126 1:   2560   1024: log(0:0)
        /dev/md126 2:   3584    512: portage(0:0)
        /dev/md126 3:   4096   1024: distfiles(0:0)
        /dev/md126 4:   5120    512: tmp(0:0)
        /dev/md126 5:   5632    256: mysql(0:0)
        /dev/md126 6:   5888    256: home(0:0)
        /dev/md126 7:   6144 524288: ftp(0:0)
        /dev/md126 8: 530432   2048: swap(0:0)
        /dev/md126 9: 532480 390144: ftp(524288:0)
        /dev/md126 10: 922624   2304: mysql(256:0)
        /dev/md126 11: 924928  28813: NULL(0:0)
        Writing vg metadata to /dev/md126 at 81408 len 3156
  Incorrect metadata area header checksum on /dev/md126 at offset 3000211603456
        Wiping pre-committed vg metadata from /dev/md126 header at 4096
  Automatic metadata correction failed
  Recovery of volume group "vg" failed.
      Unlocking /var/lock/lvm/V_vg
        _undo_flock /var/lock/lvm/V_vg
        Closed /dev/md126
        Failed to vg_read vg

Но как можно поправить ситуацию - не представляю. :(

-- 
Konstantin

Re: [gentoo-user-ru] LVM: incorrect metadata area header checksum

[Голубев Александр]

а сам контроллер нормально подцепился? в .36 настройки контроллеров немного в другое место переместили...
Возможно глупость сказал... просто по своему опыту.
ЗЫ: Всех с наступившим!

02.01.2011, 22:39, "Konstantin" <konstantin@astafjev.com>:
> Hello Gentoo-user-ru,
>
> Пробовал сегодня на файловом сервере обновить ядро до
> sys-kernel/hardened-sources-2.6.36-r6 и после перезагрузки обнаружил
> что при загрузке системы (RAID-6 из шести дисков - /dev/md2, на нем
> содан LVM "vg" рут находится на /dev/vg/slash) lvm не может обнаружить
> logical volumes:
>
> Incorrect metadata area header checksum
> Incorrect metadata area header checksum
> Incorrect metadata area header checksum
> Volume group "vg" inconsistent
> Incorrect metadata area header checksum
> Incorrect metadata area header checksum
> WARNING: Inconsistent metadata found for VG vg - updating to use version 29
> Incorrect metadata area header checksum
> Automatic metadata correction failed
>
> Крайне не хочется терять данные, поэтому хочу спросить совета у тех
> кто когда-нибудь сталкивался с такой проблемой.
>
> --
> Konstantin

-- 
С уважением Голубев Александр.

Re: [gentoo-user-ru] LVM: incorrect metadata area header checksum

[Konstantin]

Приветствую!

Monday, January 3, 2011, 00:46:12, Голубев Александр wrote:
> 02.01.2011, 22:39, "Konstantin" <konstantin@astafjev.com>:
>> Hello Gentoo-user-ru,
>>
>> Пробовал сегодня на файловом сервере обновить ядро до
>> sys-kernel/hardened-sources-2.6.36-r6 и после перезагрузки обнаружил
>> что при загрузке системы (RAID-6 из шести дисков - /dev/md2, на нем
>> содан LVM "vg" рут находится на /dev/vg/slash) lvm не может обнаружить
>> logical volumes:
>>
>> Incorrect metadata area header checksum
>> Incorrect metadata area header checksum
>> Incorrect metadata area header checksum
>> Volume group "vg" inconsistent
>> Incorrect metadata area header checksum
>> Incorrect metadata area header checksum
>> WARNING: Inconsistent metadata found for VG vg - updating to use version 29
>> Incorrect metadata area header checksum
>> Automatic metadata correction failed
>>
>> Крайне не хочется терять данные, поэтому хочу спросить совета у тех
>> кто когда-нибудь сталкивался с такой проблемой.

> а сам контроллер нормально подцепился? в .36 настройки контроллеров
> немного в другое место переместили...
> Возможно глупость сказал... просто по своему опыту.

Дело тут уже похоже совсем не в ядре, так как я запускаю систему
теперь только с livecd (пробовал уже разные версии). По какой-то
причине испортились заголовки в LVM. Сами SATA диски я вижу отлично и
RAID тоже функционирует исправно.

Похоже чтобы восстановить LVM хедеры мне нажо как-то задампить
следующие блоки:

livecd ~ # pvck -d -v /dev/md126
    Scanning /dev/md126
  Incorrect metadata area header checksum on /dev/md126 at offset 3000211603456
  Found label on /dev/md126, sector 1, type=LVM2 001
  Found text metadata area: offset=4096, size=192512
    Found LVM2 metadata record at offset=74752, size=3072, offset2=0 size2=0
    Found LVM2 metadata record at offset=71680, size=3072, offset2=0 size2=0
    Found LVM2 metadata record at offset=68608, size=3072, offset2=0 size2=0
    Found LVM2 metadata record at offset=65536, size=3072, offset2=0 size2=0
    Found LVM2 metadata record at offset=62464, size=3072, offset2=0 size2=0
    Found LVM2 metadata record at offset=58880, size=3584, offset2=0 size2=0
    Found LVM2 metadata record at offset=53760, size=5120, offset2=0 size2=0
    Found LVM2 metadata record at offset=48640, size=5120, offset2=0 size2=0
    Found LVM2 metadata record at offset=43520, size=5120, offset2=0 size2=0
    Found LVM2 metadata record at offset=38400, size=5120, offset2=0 size2=0
    Found LVM2 metadata record at offset=33280, size=5120, offset2=0 size2=0
    Found LVM2 metadata record at offset=28160, size=5120, offset2=0 size2=0
    Found LVM2 metadata record at offset=23040, size=5120, offset2=0 size2=0
    Found LVM2 metadata record at offset=17920, size=5120, offset2=0 size2=0
    Found LVM2 metadata record at offset=12800, size=5120, offset2=0 size2=0
    Found LVM2 metadata record at offset=7680, size=5120, offset2=0 size2=0
  Found text metadata area: offset=3000211603456, size=131072
  Incorrect metadata area header checksum on /dev/md126 at offset 3000211603456

И посмотреть что в них записано и какие есть различия. Как проще всего
это сделать используя gentoo install minimal cd?

> ЗЫ: Всех с наступившим!

От меня тоже примите поздравления! :)

-- 
Konstantin

Re: [gentoo-user-ru] LVM: incorrect metadata area header checksum

[Alexander Tiurin]

On Mon, 3 Jan 2011 01:39:17 +0200
Konstantin <konstantin@astafjev.com> wrote:

K> Приветствую!
K> 
K> Monday, January 3, 2011, 00:46:12, Голубев Александр wrote:
K> > 02.01.2011, 22:39, "Konstantin" <konstantin@astafjev.com>:
K> >> Hello Gentoo-user-ru,
K> >>
K> >> Пробовал сегодня на файловом сервере обновить ядро до
K> >> sys-kernel/hardened-sources-2.6.36-r6 и после перезагрузки
K> >> обнаружил что при загрузке системы (RAID-6 из шести дисков
K> >> - /dev/md2, на нем содан LVM "vg" рут находится на /dev/vg/slash)
K> >> lvm не может обнаружить logical volumes:
K> >>
K> >> Incorrect metadata area header checksum
K> >> Incorrect metadata area header checksum
K> >> Incorrect metadata area header checksum
K> >> Volume group "vg" inconsistent
K> >> Incorrect metadata area header checksum
K> >> Incorrect metadata area header checksum
K> >> WARNING: Inconsistent metadata found for VG vg - updating to use
K> >> version 29 Incorrect metadata area header checksum
K> >> Automatic metadata correction failed
K> >>


Гугл выкидывает интересные комбинации на "Recover logical
volume metadata". Может, там что-то найдется нужное. 

Re: [gentoo-user-ru] LVM: incorrect metadata area header checksum

[Konstantin]

Приветствую!

Monday, January 3, 2011, 02:06:32, Alexander Tiurin wrote:

> On Mon, 3 Jan 2011 01:39:17 +0200
> Konstantin <konstantin@astafjev.com> wrote:

K>> Приветствую!
K>> 
K>> Monday, January 3, 2011, 00:46:12, Голубев Александр wrote:
K>> > 02.01.2011, 22:39, "Konstantin" <konstantin@astafjev.com>:
K>> >> Hello Gentoo-user-ru,
K>> >>
K>> >> Пробовал сегодня на файловом сервере обновить ядро до
K>> >> sys-kernel/hardened-sources-2.6.36-r6 и после перезагрузки
K>> >> обнаружил что при загрузке системы (RAID-6 из шести дисков
K>> >> - /dev/md2, на нем содан LVM "vg" рут находится на /dev/vg/slash)
K>> >> lvm не может обнаружить logical volumes:
K>> >>
K>> >> Incorrect metadata area header checksum
K>> >> Incorrect metadata area header checksum
K>> >> Incorrect metadata area header checksum
K>> >> Volume group "vg" inconsistent
K>> >> Incorrect metadata area header checksum
K>> >> Incorrect metadata area header checksum
K>> >> WARNING: Inconsistent metadata found for VG vg - updating to use
K>> >> version 29 Incorrect metadata area header checksum
K>> >> Automatic metadata correction failed
K>> >>


> Гугл выкидывает интересные комбинации на "Recover logical
> volume metadata". Может, там что-то найдется нужное. 

Уже усиленно гуглю. Насколько понимаю главное для меня сейчас найти
именно этот lvm backup файл. Так как md доступен, то мне надо
просканировать  этот массив на предмет следующей строки:

# Generated by LVM2

как это можно правильно сделать из под gentoo minimal livecd?

а также мне уже удалось командой:

livecd gentoo # dd if=/dev/md126 bs=512 count=255 skip=0 of=/tmp/md2-raw-start

вытащить циклический текст, который скорее всего и будет необходимым
мне файлом.

vg {
id = "RyQ0r4-vERQ-gSum-35Fo-EL08-LcBI-VauxJ5"
seqno = 29
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192
max_lv = 0
max_pv = 0

physical_volumes {

pv0 {
id = "w38Lom-rIpL-6N8Z-LP4a-H2ys-tjYO-cZW4Gx"
device = "/dev/md2"

status = ["ALLOCATABLE"]
flags = []
dev_size = 7813051008
pe_start = 384
pe_count = 953741
}
}

logical_volumes {

slash {
id = "8zUXvb-pzTc-2ZY5-do6j-GQbG-dZIx-QYAFaP"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1

segment1 {
start_extent = 0
extent_count = 2560

type = "striped"
stripe_count = 1        # linear

stripes = [
"pv0", 0
]
}
}

log {
id = "BRw7wy-V4qc-0Sff-eQQh-0bzd-draw-1zAp2s"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1

segment1 {
start_extent = 0
extent_count = 1024

type = "striped"
stripe_count = 1        # linear

stripes = [
"pv0", 2560
]
}
}

portage {
id = "cFYuOq-rE1J-ZWHz-m7wP-8Nyx-2411-dFn1aC"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1

segment1 {
start_extent = 0
extent_count = 512

type = "striped"
stripe_count = 1        # linear

stripes = [
"pv0", 3584
]
}
}

distfiles {
id = "XxJn3j-NCeW-GdPs-VWCE-ZwlR-loZs-51pTUo"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1

segment1 {
start_extent = 0
extent_count = 1024

type = "striped"
stripe_count = 1        # linear

stripes = [
"pv0", 4096
]
}
}

tmp {
id = "vJ37a9-OVL1-z892-ktBl-A7i3-oED3-2nxSqJ"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1

segment1 {
start_extent = 0
extent_count = 512

type = "striped"
stripe_count = 1        # linear

stripes = [
"pv0", 5120
]
}
}

mysql {
id = "GG21Yh-0Lk4-GEO3-Jzwd-IoUq-MfFS-23hIrM"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 2

segment1 {
start_extent = 0
extent_count = 256

type = "striped"
stripe_count = 1        # linear

stripes = [
"pv0", 5632
]
}
segment2 {
start_extent = 256
extent_count = 2304

type = "striped"
stripe_count = 1        # linear

stripes = [
"pv0", 922624
]
}
}

home {
id = "eHrUny-mlx7-Of8E-LNHl-KCa2-mshA-52nDnx"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1

segment1 {
start_extent = 0
extent_count = 256

type = "striped"
stripe_count = 1        # linear

stripes = [
"pv0", 5888
]
}
}

ftp {
id = "R3Eczc-Q5x6-Diqc-AO9K-r6MR-Glfo-8QwLlq"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 2

segment1 {
start_extent = 0
extent_count = 524288

type = "striped"
stripe_count = 1        # linear

stripes = [
"pv0", 6144
]
}
segment2 {
start_extent = 524288
extent_count = 390144

type = "striped"
stripe_count = 1        # linear

stripes = [
"pv0", 532480
]
}
}

swap {
id = "39jgJ1-CqDn-Pl93-kzFt-YyhH-FWv7-7ye2zX"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1

segment1 {
start_extent = 0
extent_count = 2048

type = "striped"
stripe_count = 1        # linear

stripes = [
"pv0", 530432
]
}
}
}
}
# Generated by LVM2 version 2.02.56(1) (2009-11-24): Tue Mar 30 21:52:19 2010

contents = "Text Format Volume Group"
version = 1

description = ""

creation_host = "ftp"   # Linux ftp 2.6.28-hardened-r9 #3 SMP Sun Nov 22 05:00:39 EET 2009 i686
creation_time = 1269975139      # Tue Mar 30 21:52:19 2010


Боязнь потерять данные, останавливает от поспешных попыток
восстановления LVM метаданных. Делать резервную копию размером почти в
4 терабайта тоже сейчас не представляется возможным. Хочется бить уже
наверняка.

-- 
Konstantin

Re: [gentoo-user-ru] [SOLVED] LVM: incorrect metadata area header checksum

[Konstantin]

Приветствую!

Monday, January 3, 2011, 02:40:29, Konstantin wrote:
> Monday, January 3, 2011, 02:06:32, Alexander Tiurin wrote:
>> On Mon, 3 Jan 2011 01:39:17 +0200
>> Konstantin <konstantin@astafjev.com> wrote:
K>>> Monday, January 3, 2011, 00:46:12, Голубев Александр wrote:
K>>> > 02.01.2011, 22:39, "Konstantin" <konstantin@astafjev.com>:
K>>> >> Hello Gentoo-user-ru,
K>>> >>
K>>> >> Пробовал сегодня на файловом сервере обновить ядро до
K>>> >> sys-kernel/hardened-sources-2.6.36-r6 и после перезагрузки
K>>> >> обнаружил что при загрузке системы (RAID-6 из шести дисков
K>>> >> - /dev/md2, на нем содан LVM "vg" рут находится на /dev/vg/slash)
K>>> >> lvm не может обнаружить logical volumes:
K>>> >>
K>>> >> Incorrect metadata area header checksum
K>>> >> Incorrect metadata area header checksum
K>>> >> Incorrect metadata area header checksum
K>>> >> Volume group "vg" inconsistent
K>>> >> Incorrect metadata area header checksum
K>>> >> Incorrect metadata area header checksum
K>>> >> WARNING: Inconsistent metadata found for VG vg - updating to use
K>>> >> version 29 Incorrect metadata area header checksum
K>>> >> Automatic metadata correction failed
K>>> >>


>> Гугл выкидывает интересные комбинации на "Recover logical
>> volume metadata". Может, там что-то найдется нужное. 

> Уже усиленно гуглю. Насколько понимаю главное для меня сейчас найти
> именно этот lvm backup файл. Так как md доступен, то мне надо
> просканировать  этот массив на предмет следующей строки:

> # Generated by LVM2

> как это можно правильно сделать из под gentoo minimal livecd?

> а также мне уже удалось командой:

> livecd gentoo # dd if=/dev/md126 bs=512 count=255 skip=0 of=/tmp/md2-raw-start

> вытащить циклический текст, который скорее всего и будет необходимым
> мне файлом.

> vg {
> id = "RyQ0r4-vERQ-gSum-35Fo-EL08-LcBI-VauxJ5"

[..skipped..]

> Боязнь потерять данные, останавливает от поспешных попыток
> восстановления LVM метаданных. Делать резервную копию размером почти в
> 4 терабайта тоже сейчас не представляется возможным. Хочется бить уже
> наверняка.

Итак, эта сказка оказалась со счастливым концом, так как восстановить
данные получилось следующими командами:

# pvcreate -ff -u w38Lom-rIpL-6N8Z-LP4a-H2ys-tjYO-cZW4Gx --restorefile /tmp/lvm-seqno29 /dev/md2
# vgcfgrestore -f /tmp/lvm-seqno29 vg

Файл lvm-seqno29 я создал руками из того что нашел командами:

# dd if=/dev/md126 bs=512 count=255 skip=0 of=/tmp/md2-raw-start

и

# strings /dev/md2 | grep "# Generated by LVM" -A 2048 > md2-lvm-pattern-output.txt

Теперь я на своей шкуре ощутил насколько важно иметь резервную копию
файлов в /etc/lvm/backup/.

P.S.: Желаю всем хороших светлых праздников без потерь данных! :)

-- 
Konstantin