+++ 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