Re: [OT?] LVM questions - I have seriously screwed my system
Craig Hagerman
sure that Debian takes care of mounting the new LVM share on boot? It
didn't work for me. From what I have read online you have to create
your own startup script.
I had LVM set up successfully on my new HD, copied all the data over
from the old one and then tried to extend LVM to include the new one.
Unfortunately I made one typo and now I think I have screwed things
up. Here is what I did:
...................................................................
NOTE - sda = old HD, sdb = new HD set up with LVM
.................................................................
$ pvcreate /dev/sda2
Physical volume "/dev/sda2" successfully created
$ vgextend media_vg /dev/sda2
Volume group "media_vg" successfully extended
.... Then I tried to set up sda according to instructions on a web
site, but I wrote the wrong device without noticing....
$ fdisk /dev/sdb
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): 8e
Changed system type of partition 1 to 8e (Linux LVM)
Command (m for help): p
Disk /dev/sdb: 251.0 GB, 251000193024 bytes
255 heads, 63 sectors/track, 30515 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 1 30515 245111706 8e Linux LVM
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
WARNING: Re-reading the partition table failed with error 16: Device
or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.
So, am I totally screwed or can I recover the data and save
everything? The situation before, was that the data was mirrored on
both sda and sdb (sdb mounted as LVM at /mnt/media). But I now see
that I inadvertantly changed the partition type of sdb (when I
intended sda). So I assume that is a lost cause. (?)
Is there anything I can do now to recover?
Craig
Matthias Julius
> WARNING: Re-reading the partition table failed with error 16: Device
> or resource busy.
> The kernel still uses the old table.
> The new table will be used at the next reboot.
> Syncing disks.
This just means what is says. The disk is in use and the kernel can
not reread the partition table. You have to reboot to do that.
>
> So, am I totally screwed or can I recover the data and save
> everything? The situation before, was that the data was mirrored on
> both sda and sdb (sdb mounted as LVM at /mnt/media). But I now see
> that I inadvertantly changed the partition type of sdb (when I
> intended sda). So I assume that is a lost cause. (?)
>
> Is there anything I can do now to recover?
Actually I don't think there is anything you need to recover from.
You have set the partition type of sdb1 to LVM and that is what it
should be. That is assuming that you used sdb1 as PV and not sdb.
Now you just need to do the same for sda2 and you should be fine.
Reboot after that.
Debian will activate the VG but it will not mount the LVs automatically.
You still have to add them to /etc/fstab.
Matthias
--
To UNSUBSCRIBE, email to debian-amd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Paul Brook
> You still have to add them to /etc/fstab.
If you're using root-on-lvm you may also need to regenerate your initrd before
rebooting.
Paul
Craig Hagerman
>
> This just means what is says. The disk is in use and the kernel can
> not reread the partition table. You have to reboot to do that.
Unfortunately I did reboot before I noticed the typo. After the reboot
neither disc can be seen.
> Actually I don't think there is anything you need to recover from.
> You have set the partition type of sdb1 to LVM and that is what it
> should be. That is assuming that you used sdb1 as PV and not sdb.
But sdb1 had ALREADY been set up. Actually I had formatted it with
ext3, then followed the howto (pvcreate, vgcreate, lvcreate, mount) to
set up LVM and then copied all my old data over. So I then set the
partition type to LVM on a disc that already was set up with a VG, LV.
...now vgdisplay gives me
$ vgdisplay
Couldn't find device with uuid 'ZHl4Ak-mGS4-wFlF-4neF-G1Ed-GxWB-C4Smj6'.
Couldn't find all physical volumes for volume group media_vg.
Couldn't find device with uuid 'ZHl4Ak-mGS4-wFlF-4neF-G1Ed-GxWB-C4Smj6'.
Couldn't find all physical volumes for volume group media_vg.
Volume group "media_vg" doesn't exist
...but pvdisplay gives me encouraging news. I just don't know what to
do with this information to try to recover.
$ pvdisplay
Couldn't find device with uuid 'ZHl4Ak-mGS4-wFlF-4neF-G1Ed-GxWB-C4Smj6'.
--- Physical volume ---
PV Name /dev/sdb1
VG Name media_vg
PV Size 233.75 GB / not usable 0
Allocatable yes
PE Size (KByte) 4096
Total PE 59841
Free PE 193
Allocated PE 59648
PV UUID rlnV4y-B4eJ-Pyc0-RLJm-2Zbv-t04C-dxzU1A
--- Physical volume ---
PV Name unknown device
VG Name media_vg
PV Size 186.30 GB / not usable 0
Allocatable yes
PE Size (KByte) 4096
Total PE 47694
Free PE 47694
Allocated PE 0
PV UUID ZHl4Ak-mGS4-wFlF-4neF-G1Ed-GxWB-C4Smj6
Matthias Julius
> But sdb1 had ALREADY been set up. Actually I had formatted it with
> ext3, then followed the howto (pvcreate, vgcreate, lvcreate, mount) to
> set up LVM and then copied all my old data over. So I then set the
> partition type to LVM on a disc that already was set up with a VG, LV.
Changing the partition type does not touch the partition itself. It
just sets a flag in the partition table.
>
> ...now vgdisplay gives me
>
> $ vgdisplay
> Couldn't find device with uuid 'ZHl4Ak-mGS4-wFlF-4neF-G1Ed-GxWB-C4Smj6'.
> Couldn't find all physical volumes for volume group media_vg.
> Couldn't find device with uuid 'ZHl4Ak-mGS4-wFlF-4neF-G1Ed-GxWB-C4Smj6'.
> Couldn't find all physical volumes for volume group media_vg.
> Volume group "media_vg" doesn't exist
>
> ...but pvdisplay gives me encouraging news. I just don't know what to
> do with this information to try to recover.
>
> $ pvdisplay
> Couldn't find device with uuid 'ZHl4Ak-mGS4-wFlF-4neF-G1Ed-GxWB-C4Smj6'.
> --- Physical volume ---
> PV Name /dev/sdb1
> VG Name media_vg
> PV Size 233.75 GB / not usable 0
> Allocatable yes
> PE Size (KByte) 4096
> Total PE 59841
> Free PE 193
> Allocated PE 59648
> PV UUID rlnV4y-B4eJ-Pyc0-RLJm-2Zbv-t04C-dxzU1A
sdb1 is OK.
>
> --- Physical volume ---
> PV Name unknown device
> VG Name media_vg
> PV Size 186.30 GB / not usable 0
> Allocatable yes
> PE Size (KByte) 4096
> Total PE 47694
> Free PE 47694
> Allocated PE 0
> PV UUID ZHl4Ak-mGS4-wFlF-4neF-G1Ed-GxWB-C4Smj6
LVM does not find sda2. What does pvdisplay /dev/sda2 say?
I guess LVM only scans devices that have its type set to LVM. So it
might be enough to just do that for sda2.
Craig Hagerman
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?
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.
Goswin von Brederlow
Mounting totaly ignores the partition type anyway. So that did
nothing. But running pvcreate will have overwritten some data.
Try mounting with an alternate superblock and mount read-only and save
whatever you can.
MfG
Goswin
Lennart Sorensen
> Mounting totaly ignores the partition type anyway. So that did
> nothing. But running pvcreate will have overwritten some data.
Well if pvcreate was run, and that is all, perhaps looking at the lvm
backup data in /etc can tell what the UUID used to be and pvcreate might
allow you to tell it what uuid you want used on that device. Then lvm
should recognize it again. pvcreate doesn't overwrite the data area of
a pv, just the block containing the size and uuid and such (and the size
shouldn't have changed). Unless I am missing something in my
understanding of LVM that is. If it was not previously an lvm device,
then year whatever was there is not hurt badly.
> Try mounting with an alternate superblock and mount read-only and save
> whatever you can.
Len Sorensen
Craig Hagerman
> Mounting totaly ignores the partition type anyway. So that did
> nothing. But running pvcreate will have overwritten some data.
>
> Try mounting with an alternate superblock and mount read-only and save
> whatever you can.
>
What does it mean to "mount with an alternate superblock". I don't get
this. Can you give me an example?
On 10/20/05, Lennart Sorensen <lsor...@csclub.uwaterloo.ca> wrote:
> Well if pvcreate was run, and that is all, perhaps looking at the lvm
> backup data in /etc can tell what the UUID used to be and pvcreate might
> allow you to tell it what uuid you want used on that device. Then lvm
> should recognize it again. pvcreate doesn't overwrite the data area of
> a pv, just the block containing the size and uuid and such (and the size
> shouldn't have changed). Unless I am missing something in my
> understanding of LVM that is. If it was not previously an lvm device,
> then year whatever was there is not hurt badly.
Yes, I can open the file /etc/lvm/backup/media_vg. The IDs of the
physical volumes look OK. The PV UUID of each disc matches what is in
that file.
Craig
Goswin von Brederlow
> On Thu, Oct 20, 2005 at 03:54:12PM +0200, Goswin von Brederlow wrote:
>> Mounting totaly ignores the partition type anyway. So that did
>> nothing. But running pvcreate will have overwritten some data.
>
> Well if pvcreate was run, and that is all, perhaps looking at the lvm
> backup data in /etc can tell what the UUID used to be and pvcreate might
> allow you to tell it what uuid you want used on that device. Then lvm
> should recognize it again. pvcreate doesn't overwrite the data area of
> a pv, just the block containing the size and uuid and such (and the size
> shouldn't have changed). Unless I am missing something in my
> understanding of LVM that is. If it was not previously an lvm device,
> then year whatever was there is not hurt badly.
>
>> Try mounting with an alternate superblock and mount read-only and save
>> whatever you can.
>
> Len Sorensen
If I read that very confusing mail right then he did run pvcreate on
an ext3 filesystem. So the first superblock is probably wiped.
MfG
Goswin
Lennart Sorensen
> If I read that very confusing mail right then he did run pvcreate on
> an ext3 filesystem. So the first superblock is probably wiped.
Oh on a disk he already had data on and didn't want to use for lvm?
Yeah taht would be bad. I thought he just couldn't get the lvm started
because one of the PVs was missing.
Len Sorensen
Matthias Julius
> On 10/20/05, Matthias Julius <li...@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.