Bug 639138

Summary: parted unsets device-mapper partitions' uuids when doing a commit to a device-mapper disk
Product: [Fedora] Fedora Reporter: David Lehman <dlehman>
Component: partedAssignee: Brian Lane <bcl>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: alf, anaconda-maint-list, awilliam, bcl, donchurch, dzrudy, fedora, franta, giles, hdegoede, jlaska, johnhford, jonathan, phil.pishioneri, reub2000, rhe, vanmeeuwen+fedora
Target Milestone: ---Keywords: CommonBugs, Triaged
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard: https://fedoraproject.org/wiki/Common_F14_bugs#bios_raid_exception anaconda_trace_hash:1c9d6ac6d84cd602fb6c6edd6aca61c5e60712e844a01a7ec8f96e430c6ecb6d RejectedBlocker AcceptedNTH
Fixed In Version: parted-2.3-3.fc14 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 584328
: 649378 (view as bug list) Environment:
Last Closed: 2010-10-19 22:23:14 UTC Type: ---
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: 584328    
Bug Blocks: 635218    
Attachments:
Description Flags
lightly tested patch to preserve partitions' uuids during rescan prior to commit
none
Attached traceback automatically from anaconda.
none
Attached traceback automatically from anaconda. none

Description David Lehman 2010-09-30 22:01:24 UTC 
Created attachment 450897 [details]
lightly tested patch to preserve partitions' uuids during rescan prior to commit

This is causing anaconda to fail to discover existing storage after the first run of the live installer since it relies on the DM_UUID of the partitions being set to something sane.

+++ This bug was initially created as a clone of Bug #584328 +++

<snip>

--- Additional comment from dzrudy on 2010-08-17 22:36:13 EDT ---

Created an attachment (id=439281)
Attached traceback automatically from anaconda.

--- Additional comment from dzrudy on 2010-08-17 22:49:29 EDT ---

The traceback that I got was generated from F14 Apha RC3 Live x86_64 with all updates installed via yum (I'm using Live USB). After starting anaconda, when I got to the storage section I did the following:

1. Choose Basic Storage
2. Choose Custom Layout
3. Select one of the drives (in my case RAID 0 strip) as the one to install the system on and mark to intall bootloader on it.
4. Click Next => Crash

I can reproduce it every time and I'm unable to install the F14 alpha because of that - I need custom layout as I don't want to format my /home partition.

--- Additional comment from fedoraproject on 2010-08-19 17:33:26 EDT ---



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

--- Additional comment from reub2000 on 2010-08-24 13:23:37 EDT ---

Created an attachment (id=440705)
Attached traceback automatically from anaconda.

--- Additional comment from reub2000 on 2010-08-24 13:42:58 EDT ---

This traceback is from the Fedora 14 Alpha KDE Live CD. I start the installer, fill in information like timezone, etc. I select basic storage, then select custom layout. On the next screen I select the hard drive I want to use, click next and I get an error.

--- Additional comment from reub2000 on 2010-09-06 18:25:09 EDT ---

Tested again in the Septermber 5th nightly compose. Same bug. Will wait until beta images are released to retest unless there is activity in this thread.

--- Additional comment from jlaska on 2010-09-16 09:48:50 EDT ---

Created an attachment (id=447749)
Attached traceback automatically from anaconda.

--- Additional comment from jlaska on 2010-09-16 12:24:05 EDT ---

Created an attachment (id=447788)
Attached traceback automatically from anaconda.

--- Additional comment from dlehman on 2010-09-17 12:49:05 EDT ---

Just a note: as of F14 development this appears to be a live-only, biosraid-only bug.

--- Additional comment from jlaska on 2010-09-21 13:28:14 EDT ---

Created attachment 448755 [details]
Attached traceback automatically from anaconda.

--- Additional comment from jlaska on 2010-09-21 13:29:07 EDT ---

(In reply to comment #15)
> Just a note: as of F14 development this appears to be a live-only,
> biosraid-only bug.

See comment#16 (attachment#448755 [details]) for an NFSISO installation that encountered this issue.

--- Additional comment from jlaska on 2010-09-21 14:04:28 EDT ---

Created attachment 448764 [details]
Attached traceback automatically from anaconda.

--- Additional comment from dlehman on 2010-09-27 12:34:32 EDT ---

This is caused by biosraid devices that were mapped via device-mapper but not assigned a UUID by the same. Apparently we cannot rely on DM_UUID even existing.

--- Additional comment from reub2000 on 2010-09-27 13:04:26 EDT ---

Will there be a fix in the Beta?

--- Additional comment from dlehman on 2010-09-27 13:12:54 EDT ---

No. For most of you, however, using the non-live installer will prevent this bug from appearing.

--- Additional comment from donchurch on 2010-09-29 14:05:12 EDT ---

Created attachment 450537 [details]
Attached traceback automatically from anaconda.

--- Additional comment from donchurch on 2010-09-29 14:22:21 EDT ---

sry...I submitted a bug report (bug 638705) before repeating the install process and pasting report directly here.  They should be consolidated.

:(  I thought I could paste the output to my existing bug report.

--- Additional comment from clumens on 2010-09-29 14:28:17 EDT ---

*** Bug 638705 has been marked as a duplicate of this bug. ***

--- Additional comment from jlaska on 2010-09-29 15:08:00 EDT ---

Created attachment 450556 [details]
Attached traceback automatically from anaconda.

--- Additional comment from bcl on 2010-09-29 17:24:11 EDT ---

(In reply to comment #19)
> This is caused by biosraid devices that were mapped via device-mapper but not
> assigned a UUID by the same. Apparently we cannot rely on DM_UUID even
> existing.

If so, then this is a dupe of bug 634980 and is fixed in parted-2.3-2
Comment 1 Adam Williamson 2010-10-01 17:56:56 UTC 
This was discussed at the blocker review meeting of 2010-10-01. We agreed it doesn't meet the criteria to be a blocker (as you only hit it if you run the installer twice without rebooting), but we agreed to accept it as a nice-to-have.
Comment 2 Fedora Update System 2010-10-06 17:52:28 UTC 
parted-2.3-3.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/parted-2.3-3.fc14
Comment 3 Fedora Update System 2010-10-07 19:54:41 UTC 
parted-2.3-3.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update parted'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/parted-2.3-3.fc14
Comment 4 Adam Williamson 2010-10-19 01:06:09 UTC 
For this update to make the RC builds it needs karma. James, are you able to test the updated parted and file karma on it? I can do a quick basic function check for a confirmatory +1 if necessary.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 5 Fedora Update System 2010-10-19 22:23:08 UTC 
parted-2.3-3.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 6 giles 2010-10-21 20:58:49 UTC 
Created attachment 454938 [details]
Attached traceback automatically from anaconda.
Comment 7 John F 2010-11-03 16:26:24 UTC 
Created attachment 457490 [details]
Attached traceback automatically from anaconda.