Bug 649378 - AttributeError: 'NoneType' object has no attribute 'name'
AttributeError: 'NoneType' object has no attribute 'name'
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: parted (Show other bugs)
14
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Brian Lane
Fedora Extras Quality Assurance
anaconda_trace_hash:1c9d6ac6d84cd602f...
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-03 12:32 EDT by John F
Modified: 2012-08-16 13:07 EDT (History)
25 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 639138
Environment:
Last Closed: 2012-08-16 13:07:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
traceback from reporter (148.21 KB, text/plain)
2010-11-03 13:36 EDT, Brian Lane
no flags Details
Attached traceback automatically from anaconda. (1.20 MB, text/plain)
2010-11-04 14:36 EDT, Vasanth
no flags Details
Attached traceback automatically from anaconda. (1.91 MB, text/plain)
2010-11-04 14:58 EDT, Vasanth
no flags Details
Attached traceback automatically from anaconda. (334.72 KB, text/plain)
2010-11-05 22:18 EDT, Andrew Jamison
no flags Details
Attached traceback automatically from anaconda. (279.34 KB, text/plain)
2010-11-27 23:38 EST, sanchoooo
no flags Details
Attached traceback automatically from anaconda. (1.60 MB, text/plain)
2010-11-28 13:43 EST, sanchoooo
no flags Details
Attached traceback automatically from anaconda. (314.55 KB, text/plain)
2010-11-29 00:31 EST, sanchoooo
no flags Details
Attached traceback automatically from anaconda. (754.76 KB, text/plain)
2010-11-30 16:13 EST, Ken Farmer
no flags Details
Attached traceback automatically from anaconda. (777.10 KB, text/plain)
2010-12-28 18:04 EST, Tommy Surbakti
no flags Details
Attached traceback automatically from anaconda. (470.24 KB, text/plain)
2011-02-04 18:41 EST, Mark
no flags Details
Attached traceback automatically from anaconda. (325.50 KB, text/plain)
2011-02-21 02:54 EST, Jeremy Baudoin
no flags Details
Attached traceback automatically from anaconda. (451.08 KB, text/plain)
2011-04-19 08:21 EDT, Cameron Cross
no flags Details

  None (edit)
Description John F 2010-11-03 12:32:56 EDT
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@gmail.com on 2010-08-17 22:36:13 EDT ---

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

--- Additional comment from dzrudy@gmail.com 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@mfaux.at on 2010-08-19 17:33:26 EDT ---



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

--- Additional comment from reub2000@gmail.com on 2010-08-24 13:23:37 EDT ---

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

--- Additional comment from reub2000@gmail.com 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@gmail.com 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@redhat.com on 2010-09-16 09:48:50 EDT ---

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

--- Additional comment from jlaska@redhat.com on 2010-09-16 12:24:05 EDT ---

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

--- Additional comment from dlehman@redhat.com 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@redhat.com on 2010-09-21 13:28:14 EDT ---

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

--- Additional comment from jlaska@redhat.com 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@redhat.com on 2010-09-21 14:04:28 EDT ---

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

--- Additional comment from dlehman@redhat.com 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@gmail.com on 2010-09-27 13:04:26 EDT ---

Will there be a fix in the Beta?

--- Additional comment from dlehman@redhat.com 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@cox.net on 2010-09-29 14:05:12 EDT ---

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

--- Additional comment from donchurch@cox.net 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@redhat.com on 2010-09-29 14:28:17 EDT ---

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

--- Additional comment from jlaska@redhat.com on 2010-09-29 15:08:00 EDT ---

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

--- Additional comment from bcl@redhat.com 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@redhat.com 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@fedoraproject.org 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@fedoraproject.org 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@redhat.com 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@fedoraproject.org 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@north-row.com on 2010-10-21 16:58:49 EDT ---

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

--- Additional comment from johnhford@gmail.com on 2010-11-03 12:26:24 EDT ---

Created attachment 457490 [details]
Attached traceback automatically from anaconda.
Comment 1 John F 2010-11-03 12:41:58 EDT
to be clear, this is happening with the X86-64 install dvd, not the livecd
Comment 2 John F 2010-11-03 12:42:38 EDT
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
Comment 3 John F 2010-11-03 12:59:51 EDT
this is *also* happening with the live cd!
Comment 4 Adam Williamson 2010-11-03 13:10:31 EDT

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 5 Adam Williamson 2010-11-03 13:12:12 EDT
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
Comment 6 John F 2010-11-03 13:22:21 EDT
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.
Comment 7 John F 2010-11-03 13:23:01 EDT
https://bugzilla.redhat.com/attachment.cgi?id=457490

is from my system
Comment 8 Brian Lane 2010-11-03 13:35:08 EDT
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.
Comment 9 Brian Lane 2010-11-03 13:36:42 EDT
Created attachment 457522 [details]
traceback from reporter
Comment 10 John F 2010-11-03 13:58:57 EDT
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.
Comment 11 David Lehman 2010-11-04 01:01:32 EDT
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.
Comment 12 John F 2010-11-04 02:50:23 EDT
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.
Comment 13 Vasanth 2010-11-04 14:36:14 EDT
Created attachment 457908 [details]
Attached traceback automatically from anaconda.
Comment 14 Vasanth 2010-11-04 14:58:42 EDT
Created attachment 457914 [details]
Attached traceback automatically from anaconda.
Comment 15 Chris Lumens 2010-11-05 15:23:47 EDT
Reassigning based on comment #11, though perhaps there's a better place for this one to go.
Comment 16 Andrew Jamison 2010-11-05 22:18:18 EDT
Created attachment 458263 [details]
Attached traceback automatically from anaconda.
Comment 17 Andrew Jamison 2010-11-06 17:21:29 EDT
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.
Comment 18 John F 2010-11-06 18:03:26 EDT
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.
Comment 19 sanchoooo 2010-11-27 23:38:27 EST
Created attachment 463291 [details]
Attached traceback automatically from anaconda.
Comment 20 sanchoooo 2010-11-28 13:43:04 EST
Created attachment 463362 [details]
Attached traceback automatically from anaconda.
Comment 21 sanchoooo 2010-11-29 00:31:44 EST
Created attachment 463421 [details]
Attached traceback automatically from anaconda.
Comment 22 Ken Farmer 2010-11-30 16:13:58 EST
Created attachment 463830 [details]
Attached traceback automatically from anaconda.
Comment 23 Tommy Surbakti 2010-12-28 18:04:36 EST
Created attachment 471008 [details]
Attached traceback automatically from anaconda.
Comment 24 Mark 2011-02-04 18:41:17 EST
Created attachment 477148 [details]
Attached traceback automatically from anaconda.
Comment 25 Jeremy Baudoin 2011-02-21 02:54:29 EST
Created attachment 479837 [details]
Attached traceback automatically from anaconda.
Comment 26 Cameron Cross 2011-04-19 08:21:51 EDT
Created attachment 493179 [details]
Attached traceback automatically from anaconda.
Comment 27 Fedora End Of Life 2012-08-16 13:07:34 EDT
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

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