Bug 1004885

Summary: LVM's UUID on PV not recognized
Product: [Fedora] Fedora Reporter: Gene Czarcinski <gczarcinski>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 19CC: anaconda-maint-list, dshea, gczarcinski, g.kaviyarasu, jonathan, mkolman, sbueno, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: anaconda-20.17-1.fc20 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1008048 (view as bug list) Environment:
Last Closed: 2013-09-19 02:41:03 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1008048    
Attachments:
Description Flags
anaconda.log
none
storage.log
none
output of blkid
none
traceback from running updates-1004885.0.img none

Description Gene Czarcinski 2013-09-05 16:39:32 UTC
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

Comment 1 David Lehman 2013-09-05 16:49:28 UTC
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.

Comment 2 Gene Czarcinski 2013-09-06 18:05:48 UTC
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

Comment 3 Gene Czarcinski 2013-09-06 18:06:59 UTC
Created attachment 794929 [details]
anaconda.log

Comment 4 Gene Czarcinski 2013-09-06 18:07:48 UTC
Created attachment 794930 [details]
storage.log

Comment 5 Gene Czarcinski 2013-09-06 18:09:07 UTC
Created attachment 794931 [details]
output of blkid

Comment 6 David Lehman 2013-09-06 18:35:20 UTC
What is the error message you got? Can you attach /tmp/anaconda-tb-* to this report?

Comment 7 David Lehman 2013-09-06 18:42:56 UTC
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.

Comment 8 Gene Czarcinski 2013-09-07 13:40:29 UTC
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.

Comment 9 Gene Czarcinski 2013-09-07 13:49:10 UTC
Created attachment 795111 [details]
traceback from running updates-1004885.0.img

Comment 10 David Lehman 2013-09-09 15:34:06 UTC
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)

Comment 11 Gene Czarcinski 2013-09-09 16:15:30 UTC
+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.

Comment 12 Fedora Update System 2013-09-10 00:11:13 UTC
anaconda-20.13-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/anaconda-20.13-1.fc20

Comment 13 Fedora Update System 2013-09-10 16:24:29 UTC
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).

Comment 14 Fedora Update System 2013-09-10 19:48:35 UTC
anaconda-20.14-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/anaconda-20.14-1.fc20

Comment 15 Fedora Update System 2013-09-12 01:03:27 UTC
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 16 Fedora Update System 2013-09-14 01:05:18 UTC
anaconda-20.16-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/anaconda-20.16-1.fc20

Comment 17 Fedora Update System 2013-09-16 17:48:22 UTC
anaconda-20.17-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/anaconda-20.17-1.fc20

Comment 18 Fedora Update System 2013-09-19 02:41:03 UTC
anaconda-20.17-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.