Bug 461682

Summary:	lvm volume group names are too generic
Product:	[Fedora] Fedora	Reporter:	Michael J. Chudobiak <mjc>
Component:	anaconda	Assignee:	Dave Cantrell <dcantrell>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	billcrawford1970, ctyler.fedora, stickster, tuju
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-02-09 15:01:43 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Michael J. Chudobiak 2008-09-09 20:13:15 UTC

Anaconda always assigns generic volume group names like "VolGroup00". This is unfortunate if you need to extract data from a hard drive on a dead system by installing it in a "good" system. The odds are very high that both disks will have the same lvm volume group names, making one of them invisible.

An example scenario is given in detail here:
http://www.whoopis.com/howtos/linux_lvm_recovery.html

This happened to me "in real life", where I wanted to retrieve data from a hopelessly-messed system.

It would be much nicer if the volume group names had an element of randomness (e.g., "VG01324324132") or the host name ("caprica_vg_00") or anything at all to reduce namespace conflicts.

- Mike

Comment 1 Bug Zapper 2008-11-26 03:00:45 UTC

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 2 Chris Tyler 2008-11-28 01:06:39 UTC

*** Bug 473364 has been marked as a duplicate of this bug. ***

Comment 3 Paul W. Frields 2008-11-28 17:13:57 UTC

Although I totally agree with the practice of moving Rawhide bugs to the latest release (e.g. F10) when it happens, since this is an anaconda bug it's unlikely to be addressed unless it stays in Rawhide.  Moving back.

Comment 4 Dave Cantrell 2008-12-03 20:34:39 UTC

Patch applied to anaconda git repo:

commit 0b41f2deb4e22172c6219338d5c33aed033c3133
Author: David Cantrell <dcantrell>
Date:   Wed Dec 3 10:15:07 2008 -1000

    Better naming for LVM volume groups and logical volumes (#461682)
    
    Try to name volume groups as vg_HOSTNAME and logical volumes as
    lv_MOUNTPOINT, if we can.  Swap partitions will be lv_swapNN where
    NN is a unique number in the instance where more than one swap
    partition in use.  The / partition will get the name lv_root.
    
    Fall back on the old naming system (VolGroupNN for volume groups
    and LogVolNN for logical volumes) for people doing custom setup
    or where the hostname is localhost.
    
    For swap partition naming, tack on an NN designation when there
    are more than 1 swap partitions requested.  If only one is
    requested, it will be "lv_swap".

The new build of anaconda in rawhide will contain this change.  Please verified when you can and move the bug to CLOSED RAWHIDE if it works.

Comment 5 Juha Tuomala 2009-02-09 14:58:48 UTC

Related bug 484678.

Comment 6 Bill Crawford 2009-03-19 12:24:43 UTC

vg_HOSTNAME is insufficient if I do e.g. multiple installs on the one machine, deliberately, in order to test the upcoming release as beta or by installing rawhide. I'd advocate (for now) doing e.g. vg_f11_$HOSTNAME and then moving that to say f12 in rawhide after the release goes gold. Is it too late to consider this for f11? It's not critical, I tend to rename mine from the default anyway ...

Comment 7 Chris Tyler 2009-03-19 15:08:15 UTC

(In reply to comment #6)
> I'd advocate (for now) doing e.g. vg_f11_$HOSTNAME

But another use case is to keep the same VG over a number of sequential releases and just creating LVs within that.

For example, I often create a new LV for the root for a new version (f9root, f10root, f11root), keeping existing LVs for /home etc. I then copy appropriate config info into the new root from the old root, and drop the old root LV once things are configured and tested on the new release.

Having the release number in the VG doesn't make sense in this case.

Comment 8 Bill Crawford 2009-03-19 15:32:07 UTC

@Chris: you'd have to manually partition anyway to tell anaconda to do this, right?