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?

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:
maybe it will work?

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:
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:
And I assume that's why using the -E arg returns an error:
Or am I doing something wrong?

UPDATE: maybe this helps:
I appreciate the next suggestion.

Detailed update:

Background on the problematic drive (and a spare):
Drive: sde
Drive: sdf
Steps
duplicate the boot partition (and the 62 sectors preceding it) to the other drive (sdf):
see if the problem was duplicated to /dev/sdf
Yes, the warning now exists on sdf1 too.

This may not have been necessary...

Wanted to test this:
Did not resolve the current issue.

Test pvremove on the backup drive:
It works.

Do it for real.
Check results:
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:
See if I can fix sdf first:
No change.
That worked.

Now, how to fix sde2?
check:
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.

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.

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

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

Any idea of what was different between before & now?

Yes, this whole long thread could be boiled down to this:
I learned that removing all the partitions and even using
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
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.