Red Hat Bugzilla – Bug 493293
Anaconda crashes when probing fakeraid disks
Last modified: 2009-04-03 06:48:39 EDT
Created attachment 337479 [details]
TGZ of /tmp/*
Description of problem:
# Anaconda times out on a non-existent fd0 device
# Anaconda crashes when trying to detect arrays and stuff
Version-Release number of selected component (if applicable):
Official Beta released 31st March 2009
Steps to Reproduce:
1. remove second gfx card
2. boot from x86_64 media
3. Select language and keyboard
4. accept beta warning
6. ignore non existent fd0 device (instead of initialising it)
# arrays be found and initialised
# can't we just get rid of floppy disks once and for all!?
For my future reference:
anaconda 184.108.40.206 exception report
Traceback (most recent call first):
File "/usr/lib64/python2.6/site-packages/block/device.py", line 644, in get_le
raise NotImplementedError, "unknown dmtype %s" % (rs.dmtype,)
File "/usr/lib/anaconda/storage/devicetree.py", line 1285, in addUdevDevice
File "/usr/lib/anaconda/storage/devicetree.py", line 1486, in populate
File "/usr/lib/anaconda/storage/__init__.py", line 265, in reset
File "/usr/lib/anaconda/storage/__init__.py", line 90, in storageInitialize
File "/usr/lib/anaconda/dispatch.py", line 205, in moveStep
rc = stepFunc(self.anaconda)
File "/usr/lib/anaconda/dispatch.py", line 128, in gotoNext
File "/usr/lib/anaconda/gui.py", line 1317, in nextClicked
NameError: global name 'rs' is not defined
Thanks for reporting this, this should be fixed in anaconda-220.127.116.11-1,
which should show up in rawhide today or tomorrow.
Please check that your local mirror has anaconda-18.104.22.168-1 in the Packages
directory for rawhide, and then download boot.iso from the images dir, after
checking the boot.iso modification time + date is later then that of anaconda-22.214.171.124-1, then do (or atleast start) a network installation from the
rawhide boot.iso. It should now see both your raidsets without problems.
Please let us know if this is fixed (or not).
failed, but at least it's a different error message..
repo = http://mirrors.se.eu.kernel.org/fedora/development/x86_64/os/
i tgz'd all my logs and have attached as logs2.tgz
Created attachment 337933 [details]
2nd TGZ of /tmp/*
I'll try and jump on IRC at around 11:00am(GMT) for more direct contact.
(In reply to comment #4)
> Created an attachment (id=337933) [details]
> 2nd TGZ of /tmp/*
What you are seeing now is bug 493691, which is caused by the fix for another
dmraid bug. That fix consists of changes in both anaconda and pyblock (the
python dmraid bindings anaconda uses), unfortunately we forgot to build
a new version of pyblock together with the latest anaconda release, causing
the traceback you are now seeing.
This is fixed in python-pyblock-0.42-1.fc11, which should be on todays rawhide.
> I'll try and jump on IRC at around 11:00am(GMT) for more direct contact.
This sounds like a good plan, you can find us in #anaconda on freenode. My nick
is hansg. If no new boot.iso with the new pyblock is available around that time
I'll do an updates.img with the fixed pyblock in it for you, so that you can
test once more, and we can hopefully close this bug.
Thanks for your patience.
your last update worked a treat and i'm happy to see this bug closed. thanks heaps to all involved, this has been a thorn in my side since Fedora 8
I was away while you posted your testing results on IRC (lunch), good to hear things work now, and you are very welcome. This is something which should have been fixed long ago.