LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Hardware
User Name
Password
Linux - Hardware This forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?

Notices

Reply
 
Search this Thread
Old 03-02-2009, 09:39 PM   #1
Mountain
Member
 
Registered: Nov 2007
Location: A place with no mountains
Distribution: Kubuntu, sidux, openSUSE
Posts: 214

Rep: Reputation: 33
This error magically persists across repartitioning and all other disk changes.


How do I make this disappear?
"Incorrect metadata area header checksum"

I am willing to wipe out all data on the disk. In fact, I have deleted all partitions and started fresh several times, but I still get the error "Incorrect metadata area header checksum" when I run vgscan as soon as any new partition is put on the disk -- even non-LVM partitions.

I suspect using dd to zero out the whole disk might work, but I want a short cut... something faster than waiting a day or two for dd to zero a 1.5 TB disk.

Where is this LVM metadata persisted on the disk that enables it to reappear even after deleting all partitions?
 
Old 03-03-2009, 02:22 PM   #2
mostlyharmless
Senior Member
 
Registered: Jan 2008
Distribution: Slackware -current (multilib) with kernel 3.16.2
Posts: 1,566
Blog Entries: 13

Rep: Reputation: 178Reputation: 178
Did you use dmraid at some point? You can use dmraid -E to erase metadata.
 
Old 03-03-2009, 03:10 PM   #3
Mountain
Member
 
Registered: Nov 2007
Location: A place with no mountains
Distribution: Kubuntu, sidux, openSUSE
Posts: 214

Original Poster
Rep: Reputation: 33
Quote:
Originally Posted by mostlyharmless View Post
Did you use dmraid at some point? You can use dmraid -E to erase metadata.
I did not use dmraid, but I did partition these disks in a wide variety of ways while I was trouble shooting a boot up problem. I put LVM volume groups and logical volumes on them in a variety of ways.

However, I also used LVM to remove everything (or so I thought).

I just do this:
Code:
dd if=/dev/zero of=/dev/sdX bs=446 count=1
maybe it will work?
 
Old 03-03-2009, 03:19 PM   #4
mostlyharmless
Senior Member
 
Registered: Jan 2008
Distribution: Slackware -current (multilib) with kernel 3.16.2
Posts: 1,566
Blog Entries: 13

Rep: Reputation: 178Reputation: 178
Well, dd should work, but it is a blunderbuss to kill a mosquito, as they say.

dmraid metadata can also be written by on-board firmware raid controllers. You might have written some without knowing it if you were experimenting or got the disks used.

You could check for dmraid style metadata, (stored at the end of the disk and typically not erased by LVM or repartitioning), with dmraid -r
 
Old 03-03-2009, 03:43 PM   #5
Mountain
Member
 
Registered: Nov 2007
Location: A place with no mountains
Distribution: Kubuntu, sidux, openSUSE
Posts: 214

Original Poster
Rep: Reputation: 33
Quote:
Originally Posted by mostlyharmless View Post
Well, dd should work, but it is a blunderbuss to kill a mosquito, as they say.

dmraid metadata can also be written by on-board firmware raid controllers. You might have written some without knowing it if you were experimenting or got the disks used.

You could check for dmraid style metadata, (stored at the end of the disk and typically not erased by LVM or repartitioning), with dmraid -r
Thank you.

I'm pretty sure my problem is on sde or sde1, which was indeed part of a raid array on the Areca 1220 controller.

Here's the section from vgscan:
Code:
vgscan      /dev/sde: size is 1953525168 sectors
vgscan      /dev/sde1: size is 690732 sectors
vgscan      /dev/sde1: size is 690732 sectors
vgscan      /dev/sde1: lvm2 label detected
vgscan  Incorrect metadata area header checksum
vgscan      /dev/sdf: size is 1953525168 sectors
vgscan      /dev/sdf: size is 1953525168 sectors
vgscan      /dev/sdf: No label detected
I am assuming the "Incorrect metadata area header checksum" refers to the entries immediately above it (/dev/sde1).

But this isn't the result I expected here:
Code:
sudo dmraid -r /dev/sde1/
No RAID disks and with names: "/dev/sde1/"
Code:
sudo dmraid -r /dev/sde/
No RAID disks and with names: "/dev/sde/"
And I assume that's why using the -E arg returns an error:
Code:
 sudo dmraid -E /dev/sde1/
ERROR: option missing/invalid option combination with -E
Or am I doing something wrong?

UPDATE: maybe this helps:
Code:
o dmraid -r
No RAID disks
I appreciate the next suggestion.

Last edited by Mountain; 03-03-2009 at 04:09 PM. Reason: updated
 
Old 03-04-2009, 10:55 AM   #6
Mountain
Member
 
Registered: Nov 2007
Location: A place with no mountains
Distribution: Kubuntu, sidux, openSUSE
Posts: 214

Original Poster
Rep: Reputation: 33
Detailed update:

Background on the problematic drive (and a spare):
Drive: sde
Code:
Disk /dev/sde: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x000377d3

Partition  Boot         Start           End          Size  Id System

/dev/sde1    *             63       690,794       690,732  83 Linux
Drive: sdf
Code:
Disk /dev/sdf: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000

Partition  Boot         Start           End          Size  Id System
Steps
duplicate the boot partition (and the 62 sectors preceding it) to the other drive (sdf):
Code:
$ sudo dd bs=512 if=/dev/sde of=/dev/sdf count=690794
see if the problem was duplicated to /dev/sdf
Code:
vgscan      /dev/sde: size is 1953525168 sectors
vgscan      /dev/sde1: size is 690732 sectors
vgscan      /dev/sde1: size is 690732 sectors
vgscan      /dev/sde1: lvm2 label detected
vgscan  Incorrect metadata area header checksum
vgscan      /dev/sde2: size is 1952829270 sectors
vgscan      /dev/sde2: size is 1952829270 sectors
vgscan      /dev/sde2: No label detected
vgscan      /dev/sdf: size is 1953525168 sectors
vgscan      /dev/sdf1: size is 1953520002 sectors
vgscan      /dev/sdf1: size is 1953520002 sectors
vgscan      /dev/sdf1: lvm2 label detected
vgscan  Found duplicate PV xxxxxxxxxxxxxxxxxxx: using /dev/sdf1 not /dev/sde1
vgscan  Incorrect metadata area header checksum
Yes, the warning now exists on sdf1 too.

Code:
$ sudo tune2fs -U c1b9d5a2-f162-11cf-9ece-0020afc76f16 /dev/sdf1
This may not have been necessary...

Wanted to test this:
Code:
$ sudo dd bs=62 if=/dev/zero of=/dev/sdf count=1
Did not resolve the current issue.

Test pvremove on the backup drive:
Code:
$ sudo pvremove /dev/sdf1
$ sudo vgscan -vv
It works.

Do it for real.
Code:
$ sudo pvremove /dev/sde1
Check results:
Code:
vgscan      /dev/sde: size is 1953525168 sectors
vgscan      /dev/sde1: size is 690732 sectors
vgscan      /dev/sde1: size is 690732 sectors
vgscan      /dev/sde1: No label detected
vgscan      /dev/sde2: size is 1952829270 sectors
vgscan      /dev/sde2: size is 1952829270 sectors
vgscan      /dev/sde2: No label detected
vgscan      /dev/sdf: size is 1953525168 sectors
vgscan      /dev/sdf1: size is 1953520002 sectors
vgscan      /dev/sdf1: size is 1953520002 sectors
vgscan      /dev/sdf1: No label detected
The error is gone from both sde and sdf.

FYI => Grub0.97 is installed in the MBR of /dev/sde and looks on the same drive in partition #1 for /grub/stage2 and /grub/menu.lst.

But there are a few new problems:
Quote:
Unknown BootLoader on sde2
Unknown BootLoader on sdf2
hexdump: /dev/sdf2: No such file or directory
hexdump: /dev/sdf2: No such file or directory
See if I can fix sdf first:
Code:
$ sudo dd if=/dev/zero of=/dev/sdf bs=446 count=1
No change.
Code:
$ sudo dd if=/dev/zero of=/dev/sdf2 bs=1kB count=1
That worked.

Now, how to fix sde2?
Code:
$ sudo dd if=/dev/zero of=/dev/sde2 bs=1kB count=1
check:
Code:
$ sudo bash boot_info_script27.sh
Good. No errors. But will it boot? I don't expect a problem because I didn't mess with sde1, which is the boot partition. The MBR of sde is still in place and untouched as well. If I still have problems, I'll report back.
 
Old 03-04-2009, 01:53 PM   #7
mostlyharmless
Senior Member
 
Registered: Jan 2008
Distribution: Slackware -current (multilib) with kernel 3.16.2
Posts: 1,566
Blog Entries: 13

Rep: Reputation: 178Reputation: 178
Very interesting, I'm glad you got it fixed, I'll try to remember this one the next time someone asks about a "metadata" error.

Last edited by mostlyharmless; 03-05-2009 at 10:07 AM. Reason: missing words
 
Old 03-05-2009, 08:24 AM   #8
archtoad6
Senior Member
 
Registered: Oct 2004
Location: Houston, TX (usa)
Distribution: MEPIS, Debian, Knoppix,
Posts: 4,727
Blog Entries: 15

Rep: Reputation: 231Reputation: 231Reputation: 231
Quote:
Originally Posted by Mountain View Post
If I still have problems, I'll report back.
Actually, please report period. You've given too much to not close the issue. -- It would be nice to have you confirm that the solution works.

TIA
 
Old 03-05-2009, 11:31 AM   #9
Mountain
Member
 
Registered: Nov 2007
Location: A place with no mountains
Distribution: Kubuntu, sidux, openSUSE
Posts: 214

Original Poster
Rep: Reputation: 33
Let me update by saying that yesterday I started as I had before and put new partitions on the disks, created new LVM physical volumes, groups and logical volumes, make encrypted volumes in those LVs, and created file systems and formatted them.

After doing all that (and at stages in between), I ran all the diagnostics I ran before. Now I am not getting any of the errors I saw previously. So I think that pretty much concludes this issue.

Previously, any time I deleted the partitions and then recreated them, the errors came back. I'm not seeing that now. I'm happy
 
Old 03-07-2009, 02:50 PM   #10
archtoad6
Senior Member
 
Registered: Oct 2004
Location: Houston, TX (usa)
Distribution: MEPIS, Debian, Knoppix,
Posts: 4,727
Blog Entries: 15

Rep: Reputation: 231Reputation: 231Reputation: 231
Any idea of what was different between before & now?
 
Old 03-08-2009, 01:56 PM   #11
Mountain
Member
 
Registered: Nov 2007
Location: A place with no mountains
Distribution: Kubuntu, sidux, openSUSE
Posts: 214

Original Poster
Rep: Reputation: 33
Quote:
Originally Posted by archtoad6 View Post
Any idea of what was different between before & now?
Yes, this whole long thread could be boiled down to this:
Code:
sudo pvremove /dev/sdf1
I learned that removing all the partitions and even using
Code:
dd if=/dev/zero of=/dev/sdX bs=1k count=1
is not enough to remove the LVM metadata.

I do not know exactly where LVM stores this metadata, but it apparently isn't in the first 1k of the disk.

Most of what I did in this thread ended up being useful for me to learn and to verify my results, but in the future, if I get that error under similar circumstances, I will simply use
Code:
sudo pvremove /dev/sdX
Hopefully, this thread serves a useful supplement to the information that Google usually serves up when one enters the error message "Incorrect metadata area header checksum".

The info I found in sources such as the LVM How-To did not seem to apply to my situation (although in hindsight I can see the relationship). But I wasn't trying to recover physical volume metadata, I was trying to get rid of it.

EDIT: and the reason it was so important to me to remove this error message is that I am building a file server. I reasoned that if I couldn't start with an error-free storage state, it certainly did not make sense to begin putting all my important data on this server. So I wanted to understand and remove any and all errors I was seeing before putting this server to use.

Last edited by Mountain; 03-08-2009 at 02:00 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Repartitioning on the fly, and disk space for / LXer Syndicated Linux News 0 04-27-2007 03:01 AM
Repartitioning a Hard disk on Dell C600 running Suse 9.2 whitehawk Linux - Laptop and Netbook 2 07-08-2005 03:07 PM
repartitioning disk hda on fedora - is it worth it? jordanthompson Linux - Hardware 8 10-18-2004 02:18 PM
Repartitioning the disk dancar Linux - General 1 04-15-2004 04:04 PM
Can I just replace Windows with Linux WITHOUT repartitioning the disk?? Trying to Learn Linux - Newbie 4 01-21-2004 09:31 AM


All times are GMT -5. The time now is 08:30 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration