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
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.
parted-2.3-3.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/parted-2.3-3.fc14
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
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
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.
Created attachment 454938 [details] Attached traceback automatically from anaconda.
Created attachment 457490 [details] Attached traceback automatically from anaconda.