Bug 1004885 - LVM's UUID on PV not recognized
LVM's UUID on PV not recognized
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
19
Unspecified Linux
unspecified Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 1008048
  Show dependency treegraph
 
Reported: 2013-09-05 12:39 EDT by Gene Czarcinski
Modified: 2013-09-18 22:41 EDT (History)
8 users (show)

See Also:
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-18 22:41:03 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)
anaconda.log (6.44 KB, text/plain)
2013-09-06 14:06 EDT, Gene Czarcinski
no flags Details
storage.log (90.87 KB, text/plain)
2013-09-06 14:07 EDT, Gene Czarcinski
no flags Details
output of blkid (542 bytes, text/plain)
2013-09-06 14:09 EDT, Gene Czarcinski
no flags Details
traceback from running updates-1004885.0.img (5.21 KB, image/png)
2013-09-07 09:49 EDT, Gene Czarcinski
no flags Details

  None (edit)
Description Gene Czarcinski 2013-09-05 12:39:32 EDT
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 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.
Comment 2 Gene Czarcinski 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
Comment 3 Gene Czarcinski 2013-09-06 14:06:59 EDT
Created attachment 794929 [details]
anaconda.log
Comment 4 Gene Czarcinski 2013-09-06 14:07:48 EDT
Created attachment 794930 [details]
storage.log
Comment 5 Gene Czarcinski 2013-09-06 14:09:07 EDT
Created attachment 794931 [details]
output of blkid
Comment 6 David Lehman 2013-09-06 14:35:20 EDT
What is the error message you got? Can you attach /tmp/anaconda-tb-* to this report?
Comment 7 David Lehman 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.
Comment 8 Gene Czarcinski 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.
Comment 9 Gene Czarcinski 2013-09-07 09:49:10 EDT
Created attachment 795111 [details]
traceback from running updates-1004885.0.img
Comment 10 David Lehman 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)
Comment 11 Gene Czarcinski 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.
Comment 12 Fedora Update System 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
Comment 13 Fedora Update System 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).
Comment 14 Fedora Update System 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
Comment 15 Fedora Update System 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 16 Fedora Update System 2013-09-13 21:05:18 EDT
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 13:48:22 EDT
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-18 22:41:03 EDT
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.