This is hitting me on the release copy of Fedora 14 and is making it impossible to install on my hardware. The previous bug reports seem to be regarding the prerelease versions of Fedora 14. As I can't reopen the previous bug, I am filing this bug. I am using an X58+ICH10 (asus p6t) board and a 1TB WD Caviar black sata hard disk. +++ This bug was initially created as a clone of Bug #639138 +++ 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 --- Additional comment from awilliam on 2010-10-01 13:56:56 EDT --- 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. --- Additional comment from updates on 2010-10-06 13:52:28 EDT --- parted-2.3-3.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/parted-2.3-3.fc14 --- Additional comment from updates on 2010-10-07 15:54:41 EDT --- 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 --- Additional comment from awilliam on 2010-10-18 21:06:09 EDT --- 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 --- Additional comment from updates on 2010-10-19 18:23:08 EDT --- 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. --- Additional comment from giles on 2010-10-21 16:58:49 EDT --- Created attachment 454938 [details] Attached traceback automatically from anaconda. --- Additional comment from johnhford on 2010-11-03 12:26:24 EDT --- Created attachment 457490 [details] Attached traceback automatically from anaconda.
to be clear, this is happening with the X86-64 install dvd, not the livecd
Also, this is with 'nodmraid' on the command line. I haven't ever had a raid on this system and none of these drives have been members in a raid volume
this is *also* happening with the live cd!
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
If you don't have a RAID array, this isn't the same as the bug you cloned, I don't think. Can you copy the backtrace over to this bug? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
i have tried: -setting ide controller to 'IDE' mode -combinations of nodmraid, libata.dma=0, acpi=off, nodma=ide -both dvd and livecd -pulling my hair out None of these work for me.
https://bugzilla.redhat.com/attachment.cgi?id=457490 is from my system
I'm changing the component to anaconda. I confirmed that the distribution DVD does include the correct parted version so given that and that this isn't a RAID we need to do some more digging to find the cause.
Created attachment 457522 [details] traceback from reporter
Some progress. This disk used to be a Windows 7 64Bit boot volume. Looking at my traceback, I saw part: parted.Partition instance -- disk: <parted.disk.Disk object at 0x15bf550> fileSystem: None number: 1 path: /dev/sda1 type: 0 name: Microsoft reserved partition active: True busy: False geometry: <parted.geometry.Geometry object at 0x7f4da9a92c50> PedPartition: <_ped.Partition object at 0x15cf0b0> in the area of the backtrace that caused this crash. I booted into the LiveCD and zero'd my mbr using dd if=/dev/zero of=/dev/sda bs=512 count=1 and again with bs=100M just to be sure to wipe the MBR and a potential GPT. After doing that, anaconda in the install DVD asked me to reinitialize the drive, which it hadn't done before. I am now able to get to the partitioning stage. It would seem like reusing a Win 7 64bit boot drive for Fedora is part of the problem here.
Parted was showing an sda1 partition that was not detected by the kernel and/or udev. If parted and the kernel cannot agree about what's on the disk, anaconda is not going to be able to do much with the system.
that sounds reasonable. if the kernel and udev don't find it, maybe throwing up an error that suggests putting a new partition table on the drive would help.
Created attachment 457908 [details] Attached traceback automatically from anaconda.
Created attachment 457914 [details] Attached traceback automatically from anaconda.
Reassigning based on comment #11, though perhaps there's a better place for this one to go.
Created attachment 458263 [details] Attached traceback automatically from anaconda.
Anaconda from the install DVD threw up this error for me when telling the installer to use all free space and selected to review the partitions prior to creation. Using the 64 bit dvd. This error seems to not show up when installing via a Virtual Machine but is present when trying to install natively.
I just remembered that the partition that seemed to cause this issue that I mentioned in comment 10 had been erased long before I tried to install fedora on the system. That would suggest that parted was picking up a partition that didn't exist on the disk but did a long time ago. I guess the steps to reproduce this would be: 1. install windows 7 64 bit using the entire disk 2. use another windows 7 system to erase the entire disk and create one large ntfs partition 3. try to install fedora 14.
Created attachment 463291 [details] Attached traceback automatically from anaconda.
Created attachment 463362 [details] Attached traceback automatically from anaconda.
Created attachment 463421 [details] Attached traceback automatically from anaconda.
Created attachment 463830 [details] Attached traceback automatically from anaconda.
Created attachment 471008 [details] Attached traceback automatically from anaconda.
Created attachment 477148 [details] Attached traceback automatically from anaconda.
Created attachment 479837 [details] Attached traceback automatically from anaconda.
Created attachment 493179 [details] Attached traceback automatically from anaconda.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping