Red Hat Bugzilla – Bug 492584
Anaconda only displays the second Intel RAID set on a two RAID set configuration
Last modified: 2009-06-25 13:39:36 EDT
Description of problem:
I have the following Intel RAID configuration ( ICH9R) :
RAID Volumes :
ID Name Level Strip Size Status Bootable
0 VolOS RAID0 32KB 192.0GB Normal Yes
1 VolData RAID0 128KB 1000.3GB Notmal Yes
Port Drive Model Serial # Size Type/Status(Vol ID)
2 WDC6400AAKS-2 ... 596.2GB Normal Disk(0,1)
3 WDC6400AAKS-2 ... 596.2GB Normal Disk(0,1)
The problem is that Anaconda only displays the second RAID set : VolData.
I shall attach the output of dmraid -ay -vvv -ddd and the resulting /dev/mapper listing.
Created attachment 337021 [details]
Output of dmraid -ay -vvv -ddd
Created attachment 337022 [details]
Output of ls -l /dev/mapper after the dmraid command
I forgot to mention the version of Anaconda : 188.8.131.52
The boot.iso was downloaded from:
I have patched this issue for anaconda git from Friday 27th. On my tests it pretty much works. Would really appreciated if you can test with one of these updates images. You can find documentation on using updates in http://fedoraproject.org/wiki/Anaconda/Updates. The images are arch dependent, so use the correct one for your arch, or else it wont work.
I have downloaded both images. First of all it's strange that the i586 one is 6MB
and the x86_64 one is only 1.6 MB . I have written the x86_64 image to
a flash drive with dd . I have booted the boot.iso image from
(dated 30th March) .
When I gave the updates parameter the installer asked me to specify the device
where the updates reside and I gave the correct answer ( I verified this by
first mounting the device in the tty2 console and then unmounting it).
It found the files but gave me the error : "Exec of anaconda failed: Exec format
error", "Installed exited abnormally [1/1]" ... "You may safely reboot your
system". I have looked at the anaconda file after mounting the update and it's not
a valid Python script , it does not begin with "#!/usr/bin/python" ,
I shall attach the anaconda file.
For the x86 case it did see all the RAID sets after I set the updates parameter.
But after I choose "Create custom layout" and click "Next" it throws an exception
in the python code. I complains about the line 931 in partition_gui.py :
devname = "%s" % device.path . The error is "AttributeError: "NoneType" object has
no attribute "path"" . This seems to indicate that "device" is not properly
initialized. I have to say that this error is the same even if I don't use the
"updates" parameter in GRUB, so it's not the fault of the i586 img file.
Also the same error appears using the x86_64 boot.iso .
I hope I can help in testing this further if you could give me a proper x86_64 img
file so that anaconda sees all the RAID sets.
Thank you very muth for your patience!
The sha1 checksums for the boot.iso files (dated 30th march) downloaded from
The checksums for the update images are:
Created attachment 337261 [details]
anaconda file from 30-03-2009-1024-x86_64.img
(In reply to comment #5)
> I have downloaded both images. First of all it's strange that the i586 one is
> and the x86_64 one is only 1.6 MB .
That is strange, have to look at that.
I have written the x86_64 image to
> It found the files but gave me the error : "Exec of anaconda failed: Exec
This is what happens if you use an x86_64 image on an i586 system.
> For the x86 case it did see all the RAID sets after I set the updates
> But after I choose "Create custom layout" and click "Next" it throws an
> in the python code. I complains about the line 931 in partition_gui.py :
> devname = "%s" % device.path . The error is "AttributeError: "NoneType" object
> no attribute "path"" .
hrm I've seen this before, but not at this part of the code. Can you provide the traceback and logs. (they are at /tmp/* at installation time)
FWIW, this "path" issue might already be resolved. I have not hit it in my tests. I'll keep testing your issue and provide a new updates image at the end of the my day.
I have a Q6600 processor, 4GB RAM and Vista x64 so it's not an i586 system.
Regarding the "path" issue I think I have found in what conditions it
can be reproduced. First of all , it does not matter if you use the "updates"
parameter in GRUB. The error is apparent only if you have a flash drive
connected to the computer with an INVALID partition table, like the one
in 30-03-2009-1024-i586.img (which is an image of a partition but it does not have an MBR). So if you happen to have the flash drive connected and you hit
"Next" after choosing "Create custom layout" an exception is thrown .
I have written an empty partition table to the flash drive with fdisk. After
reboot, I went through the same steps in the installer and this time there
was no problem, the exception did not happen. Of course there is no problem
if the flash drive is not connected at all.
So what do you do if you want to use an "updates" image on a flash drive
and you don't want to have this error ? You can unplug the flash drive after
anaconda enters graphical mode (at the first installation screen). I have
verified this and indeed I was able to see all RAID sets and not have an error
after I choose "Create custom layout" and hit "Next".
Since I have 4GB RAM and and x64 processor I would like to test F11 Beta x64.
I hope the image that you'll provide me will work so that I can begin
I'll attach the logs for the x64 and x86 versions with the "path" issue.
Created attachment 337312 [details]
Anaconda logs for the "path" issue with or without the "updates" option
(In reply to comment #8)
> I have a Q6600 processor, 4GB RAM and Vista x64 so it's not an i586 system.
thiis is all good, but if you are installing from a i586 tree, then your installation will be i586 and the x86_64 image will not work. no matter what your computer has.
> So what do you do if you want to use an "updates" image on a flash drive
> and you don't want to have this error ? You can unplug the flash drive after
> anaconda enters graphical mode (at the first installation screen). I have
> verified this and indeed I was able to see all RAID sets and not have an error
> after I choose "Create custom layout" and hit "Next".
This is great! can you pls open another bugzilla for this issue. furthermore, given that you are not seeing this bug anymore and your installation was successful I'll go ahead and close this issue.
> Since I have 4GB RAM and and x64 processor I would like to test F11 Beta x64.
> I hope the image that you'll provide me will work so that I can begin
> the installation.
If you see any dmraid bugs in these tests feel free to reopen this bug.
> I'll attach the logs for the x64 and x86 versions with the "path" issue.
Use another bug for this.
Of course I used the x86_64 boot.iso :
I was dated 30th March 2009 nd the sha1 sum was:
I retested and indeed I was using the correct arch. I did an uname -a in tty2
and among other thins it said "2.6.29-16.fc11.x86_64" . I hope this clears up
I am reopening this bug as I've tested again with the image you provided
(30-03-2009-1024-x86_64.img) and it gave me the same error.
I see whats going on. This is totally my fault :), The script that was creating the images used x86_64 binaries in the i586 image, so you get those messages. pls try these:
The problem was with the x86_64 image, the i586 image worked fine (with the x86
boot.iso of course). I age tested the new images that you kindly provided and
it seems that both are for the x86 arch. In fact after extracting the contents
of both images I've have run a program that checksums all files in the resulting
folders and the contents are exactly the same!
I'm attaching a screenshot which I took in vmware so that you can see the error about ELF32, when using the x86_64 image.
Created attachment 337534 [details]
Screenshot of error with 01-04-2009-1028-x86_64.img
I;ve used an x86_64 boot.iso. The reason I used vmware here is to be able
to take a screenshot. The same error appears when I boot the iso on the
yes, this is totally expected, the x86_64 image contains files that are i586 specific. The fact that your tests succeeded with the i586 images assures me that this issue is fixed. I'm providing the x86_64 image (without so files!!!!) so you can be reassured of the result:
I have tested the latest boot.iso images for both x86_64 and x86 and they work!
The anaconda version is 184.108.40.206 . I think this bug report can be closed unless
there is someone else having these problems.
Thank you very much for your work!
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: