manually removed lvol. now what?

[thrubovc]

Hi there all,

I managed to manually remove an lvol. I still have the rvol but don't think it matters. Was messing around with lvm until I didn't think ahead and rm'd an lvol. So how do I remove it now from the VG configuration? any ideas? Thanks very much for help

[Patrick Wallek]

You can just remove the 'rlvol?' file from the /dev/vg?? directory.

After you do that you may want to do a 'vgcfgbackup /dev/vg??' so you have a backup of the vg configuration.

If you  now look at the vg with 'vgdisplay -v /dev/vg??' you should not see your LV.

NOTE:  The /dev/vg?? should be replaced with the appropriate VG name in the commands above.

[thrubovc]

you're right, but there's a catch: when I've removed the lvol28 and rlvol28, then tried creating a new one, it created it as 29, so it skipped the 28 which was logically the next step. That leads me to believing that somewhere out there, there's a VG config or some data file where this info is stored. Then I removed the 29 properly and created it again, and voila-in created 29 again. So it only skips a name when it thinks it already exists.

[Torsten.]

>> I managed to manually remove an lvol

How?

lvremove?

If you just delete the device file, the lvol definition remains.

[thrubovc]

I rm'd it, not lvremoved. that's the point, it stays in the config. now what? I mean it's not that big a deal, but it'd be nice if I knew how exactly it works. Thanks all for your responses

[Torsten.]

re-create the device file, then use lvremove.

The definition remains in the VG header until you use lvremove.

You will see this in vgdisplay.

[Matti_Kurkela · Accepted solution]

You only removed the device node used to access the LV, not the LV itself. The LV information is still in /etc/lvmtab and on the disk.

You can recover from this without even deactivating the VG.

First, you'll need to know the correct minor device number for that LV. You can find it by first creating a map file for your VG. Run this command:

vgexport -v -s -p -m /tmp/vgNAME.map vgNAME

 It will "preview" a vgexport operation, and will create a map file based on /etc/lvmtab information, just like in a real vgexport... but without actually modifying the LVM configuration at all.

Then read the map file. The first line will specify the VGID for the volume group; the other lines will include a number and a LV name. The number is important for recreating the minor device number for the LV.

Then cd to /dev/vgNAME directory and run "ll". All the device nodes will have major number 64 (or 128, if you're on HP-UX 11.31 and are using LVM 2.x).

If the major number is 64, the minor number will be of the form 0xAABBBB, where AA is specific to the VG and BBBB is the number listed in the map file for that LV presented in four-digit hexadecimal form (or all zeroes for the "group" node). If the missing LV was number 28 in the map file and named "lvol28", first convert 28 to hexadecimal using any way you like. For example:

$ printf "%x\n" 28
1c

Then create the missing device nodes using "mknod" (replace the AA part with the correct VG-specific number, of course):

mknod /dev/vgNAME/lvol28 b 64 0xAA001c
mknod /dev/vgNAME/rlvol28 c 64 0xAA001c

If LVM 2.x is used, the major number is 128 and the minor number pattern is different (0xAAABBB if I remember correctly) but the concept is the same.

[thrubovc]

Thanks Matti,

although that vg mapfile wasn't worth much as it didn't include the LV minor numbers. The fact that I still had the character device file was important as I could just look at the minor device number of that one and create the block device file accordingly. Even If I hadn't had it, I could've easily followed the pattern in which the other device files were created. But I didn't know how to recreate the device file, so thanx for your comprehensive response

[Bill Hassell]

In general, using rm in /dev is the wrong thing to do. This goes for VLM, disks, tapes, ptys, etc. There are specific commands for each type of device file such as rmsf for hardware devices like disks/LUNs and tapes, lvremove and vgremove/vgexport for LVM and so on. There are two steps to remove an lvol:

1. umount the lvol if it is a filesystem, or otherwise stop any processes using it for raw mode access.

2. lvremove /dev/vg---/lvol---

The /dev device file will be handled properly by the lvremove command. Use vgdisplay -v to see all the lvols that are defined. You can also get a quick list of active volumes with:

strings /etc/lvmtab

Note that lvmtab is a binary file with some text strings in it, so ignore strange characters.

Now the name of a new lvol (using lvcreate) is sequential, but you can change the name explicitly with the -n option.

In your case however, there would have been an error because lvmtab knows about lvol28. Removing the /dev file partially corrupts the LVM definitions.

[Matti_Kurkela]

Yes, the LV minor number is not completely specified in the map file... but the map file does contain the lower bits of the minor number.

Here's a "ll" listing from a certain VG:

crw-r--r--   1 root       sys         64 0x210000 Sep  7  2009 group
brw-r-----   1 root       sys         64 0x210001 Sep  7  2009 lvol1
brw-r-----   1 root       sys         64 0x210002 Sep  7  2009 lvol2
brw-r-----   1 root       sys         64 0x210003 Sep  7  2009 lvol3
crw-r-----   1 root       sys         64 0x210001 Sep  7  2009 rlvol1
crw-r-----   1 root       sys         64 0x210002 Sep  7  2009 rlvol2
crw-r-----   1 root       sys         64 0x210003 Sep  7  2009 rlvol3

And here is the corresponding map file:

VGID 3b633a9245152e36
1 lvol1
2 lvol2
3 lvol3

Note the numbers I highlighted in red in both listings. The decimal numbers in the map file will give you the low bytes of the minor device numbers. You'll just have to convert them from decimal to hex, if there are values larger than 9.

The part of the minor device number highlighted in blue is the VG number, which is always the same in all devices belonging to the same VG. If you have even a single device remaining after the improper "rm" operation, this is all the information you'll need to reconstruct the device files. And if all the devices are gone, you could choose a new VG number and export & re-import the VG, although this obviously requires that all the LVs in this VG are unmounted and the VG is deactivated first.

The VG number must be between 0 and the value of maxvgs kernel parameter, if such a parameter exists in your HP-UX version. If the VG belongs to a Serviceguard cluster, the VG numbers must match in all cluster nodes. (In other words, if you happened to make this mistake in a clustered system, you could look up the correct VG number from the other cluster nodes.)