Bug 461682 - lvm volume group names are too generic
Summary: lvm volume group names are too generic
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: David Cantrell
QA Contact: Fedora Extras Quality Assurance
: 473364 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2008-09-09 20:13 UTC by Michael J. Chudobiak
Modified: 2009-03-19 15:32 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-02-09 15:01:43 UTC
Type: ---

Attachments (Terms of Use)

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:

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:

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 David 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?

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