Bug 461682 - lvm volume group names are too generic
lvm volume group names are too generic
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
:
: 473364 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-09 16:13 EDT by Michael J. Chudobiak
Modified: 2009-03-19 11:32 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-09 10:01:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Michael J. Chudobiak 2008-09-09 16:13:15 EDT
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-25 22:00:45 EST
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-27 20:06:39 EST
*** Bug 473364 has been marked as a duplicate of this bug. ***
Comment 3 Paul W. Frields 2008-11-28 12:13:57 EST
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 David Cantrell 2008-12-03 15:34:39 EST
Patch applied to anaconda git repo:

commit 0b41f2deb4e22172c6219338d5c33aed033c3133
Author: David Cantrell <dcantrell@redhat.com>
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 09:58:48 EST
Related bug 484678.
Comment 6 Bill Crawford 2009-03-19 08:24:43 EDT
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 11:08:15 EDT
(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 11:32:07 EDT
@Chris: you'd have to manually partition anyway to tell anaconda to do this, right?

Note You need to log in before you can comment on or make changes to this bug.