Bug 498602 - Traceback when reviewing partition layout
Traceback when reviewing partition layout
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Chris Lumens
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: F11Target
  Show dependency treegraph
Reported: 2009-05-01 08:53 EDT by Josh Boyer
Modified: 2010-06-28 08:18 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-06-28 08:18:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Attached traceback automatically from anaconda. (159.10 KB, text/plain)
2009-05-01 08:53 EDT, Josh Boyer
no flags Details
Attached traceback automatically from anaconda. (118.12 KB, text/plain)
2009-06-17 16:21 EDT, Jarod Wilson
no flags Details

  None (edit)
Description Josh Boyer 2009-05-01 08:53:28 EDT
The following was filed automatically by anaconda:
anaconda exception report
Traceback (most recent call first):
  File "/usr/lib/anaconda/iw/partition_gui.py", line 813, in populate
    if not part.active or not device.bootable:
  File "/usr/lib/anaconda/iw/partition_gui.py", line 1339, in getScreen
    self.populate(initial = 1)
  File "/usr/lib/anaconda/gui.py", line 1414, in setScreen
    new_screen = self.currentWindow.getScreen(anaconda)
  File "/usr/lib/anaconda/gui.py", line 1331, in nextClicked
    self.setScreen ()
AttributeError: 'NoneType' object has no attribute 'bootable'
Comment 1 Josh Boyer 2009-05-01 08:53:33 EDT
Created attachment 342081 [details]
Attached traceback automatically from anaconda.
Comment 2 Chris Lumens 2009-05-06 16:40:31 EDT
Can you provide extra information that might help us figure out how you got into this situation?  What sorts of selections did you make in the UI, and what was your initial partitioning scheme?
Comment 3 Josh Boyer 2009-05-07 07:18:04 EDT
At the time, I had selected 'Use entire drive' and clicked the 'Review partition layout' checkbox, then 'Next'.  That produced this traceback.

I'll point out that this machine/drive combo also hit bug 492154 when trying to format the disk, so I don't know if this is related or not.
Comment 4 Chris Lumens 2009-05-11 14:16:21 EDT
I believe this should be fixed as a result of the fix for bug 492154 as well.  We just did a test with the latest anaconda following your instructions and were unable to reproduce the problem.  If you do continue to see it, feel free to reopen this bug report.  Thanks.
Comment 5 Chris Lumens 2009-05-12 14:27:45 EDT
Nope, I can still reproduce this.
Comment 6 James Laska 2009-05-13 11:01:05 EDT
Adding to F11Target for now based on discussion w/ clumens.  Josh, in your estimate, does this issue fall as a "must have" or a "nice to have" for Fedora 11?
Comment 7 Josh Boyer 2009-05-13 12:08:12 EDT
(In reply to comment #6)
> Adding to F11Target for now based on discussion w/ clumens.  Josh, in your
> estimate, does this issue fall as a "must have" or a "nice to have" for Fedora
> 11?  

Ooh!  Opinion solicitation.  That's never fraught with flame-potential ;)

More seriously, being able to review the partition layout seems pretty important to me.  If this is broken generically, then I would personally consider it a "must have".  I hesitate the use the term, but it might be considered a regression from previous releases if it's not present.

If it is broken only on PowerPC, or only on Apple PowerPC, then we get into a grey area.  I still view it as a "must have", since it's sort of hard to change the partitioning of the machine after installing and reviewing it is very handy.

I'll leave the decision up to those doing the code though.
Comment 8 Chris Lumens 2009-05-13 16:48:02 EDT
It appears this happens because you need to initialize the disk.  When you
initialize a Mac disk, you're making that special partition table partition at
the beginning of the disk.  No device node is being created and no sysfs entry
is being made, so udev doesn't know about it, so it never gets added to
anaconda's device tree.  Since it's not in the device tree, we can't query for
the device later on when it comes time to display the partitioning UI.  Hence,

Now what's probably causing the device node to not be made is that somewhere,
we still have a file descriptor open on the device which prevents parted from
properly notifying the kernel.  This is going to be a real pain to track down.  I honestly don't see how we're going to be able to get this tracked down and solved before F11 needs to ship.

For now, I recommend using parted or some other disk utility to make sure
there's a disk label on the disk before anaconda gets ahold of it.  Of course
if you are seeing this problem without having to initialize the disk, this all
goes out the window.  But these are the circumstances leading to this same
traceback for me.
Comment 9 Josh Boyer 2009-05-14 10:02:29 EDT
That seems to match the scenario I was in.  The disk was uninitialized entirely, as I repurposed it from a defunct RAID array.  It also hit the partition map bug at one point, and I tried this to see if it would help.

I've since installed F10 on this machine, which seems to have coped just fine.  I suspect you are correct and that if I know try to install F11 and view the partition layout, it will work due the disk being initialized.

So the scope of this bug seems to be:

1) Apple ppc/ppc64 machine
2) Uninitialized disk
3) Review the partition layout

That would seem to be statistically rare.  I am now wondering why I seem to make things overly hard on myself.  Oh well.
Comment 10 Chris Lumens 2009-05-14 11:31:59 EDT
Well, the good news is I've got a handle on this bug and have one patch that fixes it, but I'm working on a better one.
Comment 11 Chris Lumens 2009-05-14 12:47:11 EDT
This should be fixed in the next build of anaconda.  Thanks for the debugging help.
Comment 12 Bug Zapper 2009-06-09 10:56:30 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
Comment 13 Adam Williamson 2009-06-15 17:49:12 EDT
There's a very similar, but not quite identical, trace shown in a screenshot in this (rather negative) review of Fedora 11:


I've posted a comment to ask the reviewer to file a bug, but noting this here in case he doesn't.

Fedora Bugzappers volunteer triage team
Comment 14 Jarod Wilson 2009-06-17 16:21:32 EDT
Created attachment 348339 [details]
Attached traceback automatically from anaconda.
Comment 15 Jarod Wilson 2009-06-17 16:26:22 EDT
Just hit this on an x86_64 machine with the F11 release bits. I had a firewire disk with a mac partition table attached (was checking up on bug 489518). The disk was already initialized though, and not a ppc/ppc64, contrary to comment #9.
Comment 16 Renich Bon Ciric 2009-11-30 02:31:57 EST
This happened to me in a x86_64 f12 and f11 installation on a Asus M3N32 WS Professional motherboard with 5 Hitachi 500 Gb SATA II HDDs.

I sorted out the problem. This motherboard has a "hardware raid" feature. The discs had a RAID5 configuration and that prevented anaconda from seing them.

I had to enter the raid configuration utility by hitting F10 on the bios welcome message and remove the raid configuration.

After this, just went to the bios and commanded it to use OHCI instead of RAID.

This let anaconda see the drives and ask me something about "re-initializing" the drives.

OpenSuse 11.2 seemed to be able to see this nvidia raid. It even used it. On the other hand, Mandriva didn't see it and didn't mind it either...

I'm sorry, I can't provide a traceback anymore... I did once and the bug was marked as duplicate or bug 493699: bug 539413

I hope this helps
Comment 17 Adam Williamson 2009-12-01 15:15:11 EST
Um. This bug is for a _crash_ in anaconda, not just 'not seeing' the drives. Not seeing the drives is correct if they have an incorrect or partial RAID configuration, anaconda is intended to behave this way. You can override it with the 'nodmraid' parameter, but it's not a bug.

Fedora Bugzappers volunteer triage team
Comment 18 Renich Bon Ciric 2009-12-01 20:57:58 EST
Well, it did crash and offer a traceback and all.

Did you see my bug? 539413

It shouldn't crash. And, about what you say regarding this "partial RAID". It was not partial. As I said, OpenSuse could use it without problems.

This IS a bug, IMHO.
Comment 19 Adam Williamson 2009-12-02 14:03:57 EST
if Chris Lumens marked your bug as a dupe of 493699 then your bug is 493699, he's an anaconda developer and knows what he's doing :) sorry, I didn't realize you were just reporting the same issue you'd already filed a bug on. I thought you were reporting something different.

Fedora Bugzappers volunteer triage team
Comment 20 Renich Bon Ciric 2009-12-03 01:54:41 EST
Understood! ;)
Comment 21 Hans de Goede 2009-12-09 04:09:29 EST

According to the traceback attached in comment 14, and the explanation provided in comment 15, this is still happening despite the fix you put in anaconda (according to comment 11).

Assigning this to you.
Comment 22 Bug Zapper 2010-04-27 10:02:56 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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: 
Comment 23 Bug Zapper 2010-06-28 08:18:37 EDT
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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