Bug 1004885 - LVM's UUID on PV not recognized
Summary: LVM's UUID on PV not recognized
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 19
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1008048
TreeView+ depends on / blocked
 
Reported: 2013-09-05 16:39 UTC by Gene Czarcinski
Modified: 2013-09-19 02:41 UTC (History)
8 users (show)

Fixed In Version: anaconda-20.17-1.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1008048 (view as bug list)
Environment:
Last Closed: 2013-09-19 02:41:03 UTC
Type: Bug


Attachments (Terms of Use)
anaconda.log (6.44 KB, text/plain)
2013-09-06 18:06 UTC, Gene Czarcinski
no flags Details
storage.log (90.87 KB, text/plain)
2013-09-06 18:07 UTC, Gene Czarcinski
no flags Details
output of blkid (542 bytes, text/plain)
2013-09-06 18:09 UTC, Gene Czarcinski
no flags Details
traceback from running updates-1004885.0.img (5.21 KB, image/png)
2013-09-07 13:49 UTC, Gene Czarcinski
no flags Details

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.


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