Bug 1008048 - LVM's UUID on PV not recognized
LVM's UUID on PV not recognized
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda (Show other bugs)
7.0
Unspecified Linux
unspecified Severity medium
: rc
: ---
Assigned To: Anaconda Maintenance Team
Release Test Team
:
Depends On: 1004885
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-13 20:07 EDT by Brian Lane
Modified: 2014-06-13 07:44 EDT (History)
9 users (show)

See Also:
Fixed In Version: anaconda-19.31.17-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1004885
Environment:
Last Closed: 2014-06-13 07:44:25 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Brian Lane 2013-09-13 20:07:30 EDT
+++ This bug was initially created as a clone of Bug #1004885 +++

Description of problem:
A unique form of a UUID is used by LVM for the PV (Physical Volume).  This "unique" UUID is not recognized by anaconda-kickstart when it is specified on a partition onpart=UUID=<___>

Since this is not recognized, the alternative is to specify the device which can vary depending on devices connected.

Here are some examples of blkid output:

/dev/sda1: UUID="22bb70f4-24fb-46be-b9cc-1762da8f72e3" TYPE="ext4"

/dev/sdb1: UUID="lgPZJU-9jAh-ozrj-TW9y-zMZo-TqqZ-R48cTu" TYPE="LVM2_member"

/dev/sdb2: LABEL="ssd1" UUID="78e9a903-6d42-4419-b3b2-7c24c66f5602" UUID_SUB="66a55339-25a7-4b28-aa08-e01fb810640e" TYPE="btrfs"

I have successfully used UUID specifications on regular partitions, BTRFS volumes, and BTRFS subvolumes.

Version-Release number of selected component (if applicable):
Fedora 19, anaconda-19.30.13

How reproducible:
everytime

--- Additional comment from David Lehman on 2013-09-05 12:49:28 EDT ---

Please include the relevant portion of your ks.cfg along with the logs (esp. storage.log and anaconda.log) from a failed attempt at using said ks.cfg. Thanks.

--- Additional comment from Gene Czarcinski on 2013-09-06 14:05:48 EDT ---

To keep things simple, I created a KVM virtual for testing.  I started with two disks and installed.  I then reinstalled keeping the partitions but specifying the specific partitions.  Naturally, those installations worked fine.

Then, I changed all of the --onpart=vd_ specifications to --onpart=UUID=_ specifications and as expected, anaconda had a problem.  The kickstart fragment is below and the attachments follow.
----------------------------------------------------------
# Partitions
ignoredisk --only-use=vda,vdb
#clearpart --all --initlabel --drives=vda,vdb
clearpart --none

#++1++
#part /boot --ondisk=vda --asprimary --size=500  --fstype=ext4
#part swap  --ondisk=vda --asprimary --size=2048
#++2++
#part /boot --fstype=ext4 --onpart=vda1
#part swap  --noformat    --onpart=vda2
#++3++
part /boot --fstype=ext4 --onpart=UUID=71bc3228-1ccc-408c-b485-024b16e87d6d
part swap  --noformat    --onpart=UUID=30582124-ad5f-45a4-8e5d-ac857b66ed94

#++1++
#part pv.01 --ondisk=vda --asprimary --size=500 --grow
#volgroup VGa --pesize=32768 pv.01
#logvol / --fstype=ext4 --name=root --vgname=VGa --size=1000 --grow
#++2++
#part pv.01   --noformat --onpart=vda3
#++3++
part pv.01   --noformat --onpart=UUID=ZVMWsc-FbZV-t3QL-IegT-maR0-jIex-EUmRzo
volgroup VGa --noformat pv.01
logvol /     --fstype=ext4 --name=root --vgname=VGa --useexisting

#++1++
#part pv.02 --ondisk=vdb --asprimary --size=500  --grow
#volgroup VGb --pesize=32768 pv.02
#logvol /home --fstype=ext4 --name=home --vgname=VGb --size=7680 --grow
#++2++
#part pv.02   --noformat --onpart=vdb1
#++3++
part pv.02   --noformat --onpart=UUID=CCRxVn-QMH1-WeAZ-AVeP-W0xI-fD09-yxR1hk
volgroup VGb --noformat pv.02
logvol /home --fstype=ext4 --name=home --vgname=VGb --noformat

--- Additional comment from Gene Czarcinski on 2013-09-06 14:06:59 EDT ---



--- Additional comment from Gene Czarcinski on 2013-09-06 14:07:48 EDT ---



--- Additional comment from Gene Czarcinski on 2013-09-06 14:09:07 EDT ---



--- Additional comment from David Lehman on 2013-09-06 14:35:20 EDT ---

What is the error message you got? Can you attach /tmp/anaconda-tb-* to this report?

--- Additional comment from David Lehman on 2013-09-06 14:42:56 EDT ---

You can disregard my last request for information.

I have a potential fix, which you can test by appending the following to the boot command line:

 inst.updates=http://dlehman.fedorapeople.org/updates/updates-1004885.0.img

Let me know how it goes. Thanks.

--- Additional comment from Gene Czarcinski on 2013-09-07 09:40:29 EDT ---

I am glag I have this set up in a KVM virtual so that it is easy to test.  Unfortunately, with or without specifying a kickstart file, specifying this update causes anaconda to crash almost immediately.  I am attaching a screenshot with the traceback messages.

--- Additional comment from Gene Czarcinski on 2013-09-07 09:49:10 EDT ---



--- Additional comment from David Lehman on 2013-09-09 11:34:06 EDT ---

Sorry about that -- I forgot you were using F19 (as opposed to rawhide/F20).

Here is an updates image URL that should be compatible with your version of anaconda:

  inst.updates=http://dlehman.fedorapeople.org/updates/updates-1004885.1.img

(note the '.1' as opposed to the '.0' from the previous URL)

--- Additional comment from Gene Czarcinski on 2013-09-09 12:15:30 EDT ---

+1 Good work!  That did the trick!

About the only other thing is that this:
   http://fedoraproject.org/wiki/Anaconda/Kickstart
probably needs to be updated to specifically state that the "special" LVM UUID on a PV can be used.

I set up a F20/rawhide test too.

--- Additional comment from Fedora Update System on 2013-09-09 20:11:13 EDT ---

anaconda-20.13-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/anaconda-20.13-1.fc20

--- Additional comment from Fedora Update System on 2013-09-10 12:24:29 EDT ---

Package anaconda-20.13-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-20.13-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-16296/anaconda-20.13-1.fc20
then log in and leave karma (feedback).

--- Additional comment from Fedora Update System on 2013-09-10 15:48:35 EDT ---

anaconda-20.14-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/anaconda-20.14-1.fc20

--- Additional comment from Fedora Update System on 2013-09-11 21:03:27 EDT ---

anaconda-20.15-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/anaconda-20.15-1.fc20
Comment 3 Jan Stodola 2013-10-01 09:17:26 EDT
--onpart=UUID=xyx is recognized by anaconda for LVM PVs. Tested using compose RHEL-7.0-20130926.0 with anaconda-19.31.18-1.el7 and following partitioning:

bootloader --location=mbr
part /boot --onpart=UUID=d7b891d4-d39c-4664-8d3c-4183a5632980
part pv.01 --onpart=UUID=flwCEG-Vi5q-8GK3-9UuE-c69x-izsC-7xscWQ
volgroup aa --pesize=32768 pv.01
logvol swap --fstype=swap --recommended --name=SNAKE_SWAP --vgname=aa
logvol / --grow --maxsize=10240 --size=2048 --name=SNAKEROOT --vgname=aa

Moving to VERIFIED.
Comment 4 Ludek Smid 2014-06-13 07:44:25 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

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