Re: [OT?] LVM questions - I have seriously screwed my system
Craig Hagerman <craighagerman@gmail.com> writes:
> On 10/20/05, Matthias Julius <lists@julius-net.net> 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
Reply to: