Craig Hagerman <[EMAIL PROTECTED]> writes: > On 10/20/05, Matthias Julius <[EMAIL PROTECTED]> wrote: >> >> >> LVM does not find sda2. What does pvdisplay /dev/sda2 say? > > % pvdisplay /dev/sda2 > No physical volume label read from /dev/sda2 > Failed to read physical volume "/dev/sda2" > > I guess LVM only scans devices that have its type set to LVM. So it >> might be enough to just do that for sda2. >> > > Before, the partition type for /dev/sdb1 was ext3 (ie 82). Now it is LVM > (8e). So you are saying that just by changing the partition type the data is > not effected, right? If I now change it BACK to ext3, do you suppose > everything will be mount-able?
There is no ext3 on your sdb1. There is a PV with data in it. From the old ext3 fs is certainly not much left. And the type of LVM is appropriate. And the data on there are probably OK. > > Right now sda2 is showing up as type "Linux". It was previously set to ext3 > so this looks correct, but since I created the VG and LV, I can't mount it > with mount -t ext3 .... or mount -t auto. There is no partition type ext3. All linux partitions with a filesystem have the type Linux. The type of your sda2 probably should be set to LVM. ,----[from man vgcfgrestore] | REPLACING PHYSICAL VOLUMES | vgdisplay --partial --verbose will show you the UUIDs and sizes of any | PVs that are no longer present. If a PV in the VG is lost and you wish | to substitute another of the same size, use pvcreate --restorefile file- | name --uuid uuid (plus additional arguments as appropriate) to initialise | it with the same UUID as the missing PV. Repeat for all other missing | PVs in the VG. Then use vgcfgrestore --file filename to restore the vol- | ume group's metadata. `---- I would try that. If you did not extend the LV after adding sda2 you can also run "vgreduce --removemissing vg-name" to get rid of the missing PV and to get a clean VG. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
