partition table read incorrectly
Quoted 2 lines
Other data point: the 2.2.19 kernel as found on the lnx bootable business card also gets it wrong and detect a sdb1..
But why do you call it wrong?
There is a partition table there, and a signature, and the single entry describes (in DOS-type partition table style) a partition with a length of 4GiB with System Id 0.
Some programs will call it an unused partition because of the type 0, but there is a partition there.
Andries
Quoted 1 line · Previously [email protected] wrote:
But why do you call it wrong?
I deleted all partitions with fdisk so I expect none to be there. fdisk shows none, but the kernel does.
Wichert.
Signature · 4 lines
_________________________________________________________________ / Nothing is fool-proof to a sufficiently talented fool \ | [email protected] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Quoted 5 lines · Wichert Akkerman
Quoted 1 line · Previously [email protected] wrote:
But why do you call it wrong?
I deleted all partitions with fdisk so I expect none to be there. fdisk shows none, but the kernel does.
The safest thing to do at this point is to simply delete the whole thing:
dd if=/dev/zero of=/dev/sdb count=1
then pvcreate the disk again. If you already have data on the PV in question, you can "dd if=/dev/zero of=/dev/sdb bs=1 seek=510 count=2" to remove only the partition signature.
Note also that it is a bug in LVM that it did not zero the whole thing in the first place.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
Quoted 3 lines · Previously Andreas Dilger
If you already have data on the PV in
question, you can "dd if=/dev/zero of=/dev/sdb bs=1 seek=510 count=2" to remove only the partition signature.
That helped and the kernel no longer sees that partition anymore. However LVM still doesn't work:
cloud:/dev/discs/disc1# vgscan vgscan -- reading all physical volumes (this may take a while...) vgscan -- found active volume group "vg_user" vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created vgscan -- WARNING: This program does not do a VGDA backup of your volume group
cloud:/dev/discs/disc1# vgchange -a y vgchange -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan
I did a bit of looking around and it seems the confusement is in the
kernel: when lvm_check_kernel_lvmtab_consistency() compares the kernel and the lvmtab entries the list from the kernel mentions the vg_user volume group twice, while the lvmtab only mentions it once.
Wichert.
Signature · 4 lines
_________________________________________________________________ / Nothing is fool-proof to a sufficiently talented fool \ | [email protected] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |