Tux

...making Linux just a little more fun!

Talkback:140/pfeiffer.html

[ In reference to "Encrypted Storage with LUKS, RAID and LVM2" in LG#140 ]

Andrej Kartashov [a-m-kartashov at yandex.ru]


Tue, 26 Feb 2008 17:45:39 +0600

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


Top    Back


Kapil Hari Paranjape [kapil at imsc.res.in]


Tue, 26 Feb 2008 13:56:33 +0530

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 cryptvg
Regards,

Kapil. --


Top    Back


René Pfeiffer [lynx at luchs.at]


Tue, 26 Feb 2008 09:37:12 +0100

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é.


Top    Back


Kapil Hari Paranjape [kapil at imsc.res.in]


Tue, 26 Feb 2008 14:51:00 +0530

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. --


Top    Back


René Pfeiffer [lynx at luchs.at]


Tue, 26 Feb 2008 10:42:02 +0100

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. :)


Top    Back