Created attachment 346442 [details] AttributeError: 'StorageDevice' object has no attribute 'geometry' Description of problem: Version-Release number of selected component (if applicable): anaconda-11.5.0.59-1.fc11 How reproducible: Each time Steps to Reproduce: 1. boot.iso, askmethod, http://download.redora.etc 2. Select create custom layout 3. Click next, boom! Actual results: traceback Expected results: Custom layout screens Additional info: I list this as low even tho the install will not proceed since this system is way out of the ordinary in that it has 7 hard drives, many partitions that make up boot partitions, x83 parititions, LVM and software raid with a raid5, raid10 and a raid container. HOWEVER, given all that, I would at least expect something that says some limit has been exceeded, or some other graceful way to exit. At some point, I am going to kill this configuration and start again, but don't want to do that until Fedora 12 is rolling and also if there is no other way to get anaconda to let me kill most of the configuration during install and start fresh.
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I don't suppose you know what a minimal reproducer for this bug could be, do you? Looking at the code real quick, it's obvious we are attempting to add a StorageDevice instance to the disk stripe graph, but StorageDevices are sort of an abstract class and don't provide such nice things as partedPartition instances. It's hard to tell why something's getting detected as a StorageDevice instead of a more specific class, though. At the very least, dropping into the python debugger, typing "up" several times until you get to the stripe.add(device) frame, and printing device might give us something to go on. That's if you can reproduce this, of course.
Created attachment 347087 [details] debug output of print device I can reproduce this bug with a F-11 x86_64 install DVD. Attached is screen shot of the requested debug output.
Joel - what's happening here is that your patch in storage/devicetree.py that creates StorageDevices when udev tells us something is on dmraid is screwing up the disk slice graph in iw/partition_gui.py. All that UI code assumes we're going to be able to get our hands on a pyparted partition object (usually partedPartition, though freespace "partitions" make this a little complicated), since we need to know how big to make the slices and what sizes to display. There's some other stuff in iw/partition_gui.py that needs a partedPartition, too. This is going to need some additional work in order to correctly handle dmraid devices, I suppose. Want to take a look?
*** Bug 506733 has been marked as a duplicate of this bug. ***
*** Bug 509018 has been marked as a duplicate of this bug. ***
Can't verify fixed due to 511907
(In reply to comment #7) > Can't verify fixed due to 511907 This issue has already been resolved. can you pls test once more? Wit sofware raid I am hitting https://bugzilla.redhat.com/show_bug.cgi?id=515471, this means that you would get a message from the installer telling you that it cannot proceed. On looking at the logs, one realizes that the installer did not find a device when it wanted to zero it out. This is due to 515471. FYI. I was testing with raid10.
I will try with the Fedora 12 Alpha Test Install CD. I am not trying to install on raid even tho there are partitions making up a raid10 device (4 parts) and raid 5 device (3 parts) and a container (11 parts). Nor do I have LV over raid, just LV with ordinary PVs.
Hit this again, I believe, with 12.11. See 516557.
*** Bug 516557 has been marked as a duplicate of this bug. ***
We do not support the use of raid containers whose members are partitions. That support exists in mdadm to provide an alternative to dmraid for managing arrays configured using the BIOS. You should use mdadm's native metadata formats for arrays that you create using mdadm.
Even tho you don't support it, anaconda should not traceback because of it. Anaconda should either ignore containers (as do suse and ubuntu) dring installation or let the user know so they can take an action outside of install. I prefer the ignore option and then allow the user to use custom partitioning if they desire and build arrays that way or not. This is again an issue of software robustness. I know the storage section is new, but it shouldn't traceback even at this point if there is a configuration it can't handle.
Instead of wontfix, this should be left open as low even tho raid containers are not *yet* supported and fix the traceback so the user can make a choice at install time. I don't think I said this well in comment 13. At this point, if I want to continue testing fedora and anaconda specifically, I have deleted the container and zeroed the superblock. So, I shouldn't hit this bz again. Right?
Still present in 12.14 Please do not close this bz, keep it open and low and work on it as time permits. I know you want anaconda to be robust software and this kind of testing that I do will lead to that. Please reopen. Thanks.
(In reply to comment #12) > We do not support the use of raid containers whose members are partitions. That > support exists in mdadm to provide an alternative to dmraid for managing arrays > configured using the BIOS. You should use mdadm's native metadata formats for > arrays that you create using mdadm. Please read my comments 123, 14 and 15. Thanks.
I have a patch that should resolve this specific problem. I will apply it after the Fedora 12 Alpha is released. It is on the mailing list and references this bug id in the subject if you want to take a look or test it. I am moving this bug to ASSIGNED until I commit the patch.
I think the patch would be appropriate but it isn't necessary in my case now. I deleted the container partitions and now can select a partitioning method without a traceback occuring. Anyway, I wouldn't know how to use a patch to do a test. If there is something I can read, it would be good to know how since I read the anaconda list daily and could test some patches as they come out before the composes. You can close this bz if you like.
Fix ended up in anaconda-12.16-1.