...making Linux just a little more fun!
[ In reference to "Encrypted Storage with LUKS, RAID and LVM2" in LG#140 ]
Andrej Kartashov [a-m-kartashov at yandex.ru]
Hello,
Please pay attention to unmounting script in "Mounting and umounting" section:
================== #!/bin/sh umount /backup lvremove backuplv vgremove cryptvg cryptsetup remove crypt1 cryptsetup remove crypt2 ==================
Commands `lvremove backuplv` and `vgremove cryptvg` will remove logical volume and its volume group. It is not unmounting but ~erasing~
I knew nothing about lvm while reading your article so I deleted important data while running 'unmounting' script blindly.
Please correct the article.
Best regards,
Andrej
Kapil Hari Paranjape [kapil at imsc.res.in]
Hello,
On Tue, 26 Feb 2008, Andrej Kartashov wrote:
> ================== > #!/bin/sh > > umount /backup > lvremove backuplv > vgremove cryptvg > cryptsetup remove crypt1 > cryptsetup remove crypt2 > ================== > > Commands `lvremove backuplv` and `vgremove cryptvg` will remove logical volume > and its volume group. It is not unmounting but ~erasing~
I don't recall the precise context but I suppose that should have been
lvchange -an backuplv vgchange -an cryptvgRegards,
Kapil. --
René Pfeiffer [lynx at luchs.at]
Hello!
On Feb 26, 2008 at 1356 +0530, Kapil Hari Paranjape appeared and said:
> Hello, >=20 > On Tue, 26 Feb 2008, Andrej Kartashov wrote: > > #!/bin/sh > > > > umount /backup > > lvremove backuplv > > vgremove cryptvg > > cryptsetup remove crypt1 > > cryptsetup remove crypt2 > > > > Commands `lvremove backuplv` and `vgremove cryptvg` will remove logical volume > > and its volume group. It is not unmounting but ~erasing~ > > I don't recall the precise context but I suppose that should have been > lvchange -an backuplv > vgchange -an cryptvg
I think both work. I just checked my backup server (which runs Debian Etch). It has both commands.
shinare:~# which lvremove /sbin/lvremove shinare:~# which lvchange /sbin/lvchange shinare:~#
The commands are symlinked to "lvmiopversion".
shinare:~# ls -l /sbin/lvremove lrwxrwxrwx 1 root root 13 2006-11-24 23:40 /sbin/lvremove -> lvmiopversion shinare:~# ls -l /sbin/lvchange lrwxrwxrwx 1 root root 13 2006-11-24 23:40 /sbin/lvchange -> lvmiopversion shinare:~#"lvmiopversion" is part of the lvm-common package. Maybe I should have mentioned this detail since other distributions might use a different scheme.
Best wishes, René.
Kapil Hari Paranjape [kapil at imsc.res.in]
Hello,
On Tue, 26 Feb 2008, Ren? Pfeiffer wrote:
> On Feb 26, 2008 at 1356 +0530, Kapil Hari Paranjape appeared and said: > > I don't recall the precise context but I suppose that should have been > > lvchange -an backuplv > > vgchange -an cryptvg > > I think both work. I just checked my backup server (which runs Debian > Etch). It has both commands.
Just because the underlying binary is the same does not mean that the functionality is the same!
"lvchange -an" and "vgchange -an" mark the corresponding logical volume (respectively volume group) "inactive".
One can reactivate them using "-ay" instead of "-an".
On the other hand "lvremove" and "vgremove", remove the logical volume (respctively volume group). This means that one must re-create these. In the process, the logical volume make get assigned entirely different blocks and so the original data is lost. The volume group will also get re-initisalised so that all logical volume metadata associated with the volume group will be lost.
As a practical example do the following.
Setup:
1. Create a volume group (say on a loopback device based on a large file). 2. Create a logical volume on that volume group. 3. Create a file system on that logical volume.
Test with lvchange/vgchange:
1. Run "lvchange -an" on the logical volume. 2. Do various things which do not involve that logical volume for example create more logical volumes in the same volume group. 3. Run "lvchange -ay" on the original logical volume. 4. Run fsck on the original logical volume. 5. Do the same tests with "vgchange".
Test with lvremove and vgremove: Do 1-5 above with these commands in place of the "change" commands.
I expect you will see file-system errors in the second set of tests but not in the first set of tests.
Regards,
Kapil. --
René Pfeiffer [lynx at luchs.at]
Hello!
On Feb 26, 2008 at 1451 +0530, Kapil Hari Paranjape appeared and said:
> On Tue, 26 Feb 2008, René Pfeiffer wrote: > > On Feb 26, 2008 at 1356 +0530, Kapil Hari Paranjape appeared and said: > > > I don't recall the precise context but I suppose that should have been > > > lvchange -an backuplv > > > vgchange -an cryptvg > > > > I think both work. I just checked my backup server (which runs Debian > > Etch). It has both commands. > > Just because the underlying binary is the same does not mean that the > functionality is the same!
You are absolutely right. I think I wasn't awake yet when I wrote my
answer. 
> "lvchange -an" and "vgchange -an" mark the corresponding logical > volume (respectively volume group) "inactive". > > One can reactivate them using "-ay" instead of "-an". > > On the other hand "lvremove" and "vgremove", remove the logical > volume (respctively volume group). This means that one must re-create > these. In the process, the logical volume make get assigned entirely > different blocks and so the original data is lost. The volume group > will also get re-initisalised so that all logical volume metadata > associated with the volume group will be lost.
This is very crucial and I really should have mentioned this. I only used test volumes for the preparation of my articles and I think I would have tested more thoroughly if I had worked on volumes containing valuable data.
> [...] > I expect you will see file-system errors in the second set of tests > but not in the first set of tests.
Yes, I think you will.
Best regards,
René,
who also advises to triple check the device mappings prior to
initialising an encrypted storage device. XFS doesn't like it when you
shuffle its inodes with cryptsetup on the block device where a
filesystem is mounted. "Use the --force!" isn't always good advice.