archive mirror
 help / color / mirror / Atom feed
* [linux-lvm] Possible Bug vgrename
@ 2021-06-21 18:32 N
  2021-06-21 19:48 ` David Teigland
  0 siblings, 1 reply; 3+ messages in thread
From: N @ 2021-06-21 18:32 UTC (permalink / raw)
  To: linux-lvm

Hello, I'm hoping someone has an idea on how to go about working around 
this better.

I've run into issues working with lvm2, vgrename several times now in 
the past. I've got a bit more time now so I thought I'd reach out to see 
if there was another way of doing this.

Sometimes its necessary to access a volume group that has a naming 
conflict on the system being used, its usually during a temporary 
procedure and attaching the drive creates a temporary naming conflict, 
the volumes are listed as inactive and you need to access the data 
(often to create an emergency backup). You can easily change the name 
with vgrename and rescan to access the volumes, but to undo those 
changes it is problematic.

To revert the change usually requires additional time, and then the 
vgrename changes after rebooting into a recovery environment to undo the 
Even with the volumes deactivated, as long as the volume group conflict 
remains, vgrename will not set the name to a conflicting name even with 
the force flag set (i.e. when referencing the volume using UUID).

The issue has been common enough that when I set up systems that use 
lvm2 I usually just randomize the volume group names with output from 
uuidgen but this does not help me much when the system isn't set up by 
me initially.

vgrename fails to change the groupname for a set of volumes referenced 
by UUID to a name that it knows is in conflict with any of the existing 
previously scanned volume group names.

Systems using encryption at-rest often will fail to boot if the volume 
group name has been changed, and this can all add up to quite a bit of 
additional time needed when resolving any issues. Even more time when a 
disk subsystem needs to go through a set startup sequence after each 
shutdown/restart (~10-15m).

Is there a way to temporarily rename (without actually renaming) the 
volume groups (i.e. like setting a mask for the volume group names), or 
is there a way to force vgrename to actually make the change even if 
there is an existing conflict (preferably without a reboot)?

The force flag in the documentation fails to make any changes, I ran a 
test to confirm just recently and confirmed this is still an issue. In 
most cases, the conflict, is with a root volume on the system being used 
so its often either not possible, or expedient to rename that volume 
group to resolve the naming conflict.

Appreciate any help you all can provide.

Best Regards,

Nathan Singer

linux-lvm mailing list
read the LVM HOW-TO at

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-06-21 20:00 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-21 18:32 [linux-lvm] Possible Bug vgrename N
2021-06-21 19:48 ` David Teigland
2021-06-21 20:00   ` Alasdair G Kergon

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).