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

Discovered while trying a live install on a DMRAID system previously installed with 2 RAID10 devices and encryption.

This is fixed in pyblock-0.44, which is in the updates.img I provided (and in koji, and requested to be included in F-12). Since this is a live install I guess you did not use the updates.img, closing.

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

I try install FC12 Beta with all latest updates.

I have MB Asus P5K-E on P35 chipset.
So, I have installed Raid-0 (Stripe) on ICH9R, and 3rd hdd as JBod.
Need any additional information about my hardware?

I tried to find any solutions, but always have this error.

P.S.: FC11 installed normally, without any problem.

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

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

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

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

seems this is still happening in F12 final, with both the gnome X86-64 live (which is why i'm on this bug) and the kde X86-64 live cd which i reported in BZ:538567. is there any workaround for this? or yet again have i wasted over a GB of bandwidth of a fedora release that wont install on an raid set :(

Ok,

Looking at this bug, all reports seem to try to be doing live installs. I'm not saying that those should not work, but that seems to be part of the problem.

Besides that anaconda thinks that all of you are using BIOS RAID, some of you may in fact not be using BIOS RAID, but have metadata on your disk from when they were used as part of a BIOS RAID set in the past, see:
https://fedoraproject.org/wiki/Common_F11_bugs#Installer_ignores_incomplete_BIOS_RAID_array_disks.2C_nodmraid_kernel_parameter_not_honored

So let me go over this on a case by case basis:

1) gengzu

You say your disks are RAID on an ICH9R chipset, but your logfile says:
type detected on 'sda' is 'nvidia_raid_member', and metadata for a valid nvidia raid set gets found on your disks. However I also see an md-127 in the devices
found, so you probably also have some Intel BIOS RAID metadata on one of your disks. The installer crashes when it tries to activate the nvidia raidset, which
probably means that there actually is an issue where one of the disks of the set
is already in use in some way, try de-activating all volume groups, etc, before starting anaconda. Note that the liveinst shell script already tries this, but
maybe it fails.

2) Anril

You seem to have a promise BIOS RAID set, which somehow is still in use
when the installer starts, looking at the number of dm-0 device nodes in the
logs lvm was still active when the installer started, try de-activating it manually, before starting the installer.

3) jacobinos

Your first disk seems to be normally used, and your second and third disk together are a nvidia BIOS RAID set, other then that, see 2).

4) Phil,

Your first disk seems to be normally used, and the rest (plenty of them) are
part of a nvidia BIOS RAID set I think, other then that see 2).


So all in all the biggest problem seems to be that the liveinst script fails to
deactivate things like lvm etc, as they are in use by something. There is little
which can be done in the installer here (*)

Since clearly a lot of people are hitting this I will propose (to the rest of the team) to modify the liveinst script to make being unable to de-activate lvm (and other things we need to have in a de-activated state when starting the installer), fatal, with a dialog asking the user to manually de-activate things.

* this is a problem with running the installer in a livecd environment, try using the installation dvd instead, or do a network install, that way if anaconda crashes in the storage setup, you've only used 150 MB of bandwidth.

I'm leaving this bug open for now and I would like to hear back from you if manualyl de-activating things and / or using the install dvd / doing a network install helps.


p.s.

gengzu your case seems special, please try again with Fedora-12 final, and get back to me if you are still having issues.

thanks for the info hans, my setup is like this

dev/sda 500Gb total, 1 500Gb ntfs partition sda1 contains music, movies, photo's etc  
dev/sdb 20Gb total , 1 20Gb ntfs partition contains winxp
dev/sdc}
       } 2 x 250Gb as /dev/mapper/nvidia_eaiajjfa raid0 dmraid
dev/sdd}
dev/sde 16Gb usb drive containing live image

contents of /dev/mapper/nvidia_eaiajjfa
/dev/mapper/nvidia_eaiajjfap1 1069mb ext3 fedora 11 'boot'
/dev/mapper/nvidia_eaiajjfap2 100Gb ext4 fedora 11 '/'
/dev/mapper/nvidia_eaiajjfap3 100Gb ext3 backtrack4pre '/'
/dev/mapper/nvidia_eaiajjfap4 extended partition containing
>>>>>>>/dev/mapper/nvidia_eaiajjfap5 285Gb ext3 backups, virt machines etc
>>>>>>>/dev/mapper/nvidia_eaiajjfap6 4Gb linux-swap

as you can see f11 and backtrack4-pre(ubuntu 8.10 based distro) installed to the bios raid array without problems so i can't understand why f12 can't?

how can i turn off the raid array when using the live usb? 

if i can't figure out how to turn off the raid array to let the installer get past device detection i will have a look at doing a net install as i don't want to waste 4Gb of bandwidth on the installer dvd in case it doesn't work either, as bandwidth costs me money :(

thanks again for the help
phil

ok i tried booting the live cd's with 'nodmraid' and while this got me slightly farther, unfortunately none of the drives from the raid array were shown as possible installation targets, so i then started the raid array with

$ dmraid -ay -f nvidia 

and re-started the install, with this anaconda saw the drives but said i had to re-initialise them (wipe them!!) if i wanted to use them, this was no use!

i also purchased an F12 install dvd and it arrived today and it did install perfectly well on the same machine, and i'm sure that with your red-hat 'hat' on you will be perfectly happy with this, but as for fedora the live cd's are the most downloaded and distributed methods of install and i really think that anaconda should also work with the live cd install method too.

also would it be possible to do something like make a partition to install F12 too (eg /dev/sda1) then start the live cd and 

mkdir /mnt/f12
mount /dev/sda1 /mnt/f12/
cp --preserve -R /{bin,dev,home,root,usr,boot,etc,lib,opt,selinux,srv,sbin,var} /mnt/f12/
mkdir /mnt/f12/{mnt,tmp,proc,sys}
chmod 1777 /mnt/f12/tmp/
mount -t proc proc /mnt/f12/proc/
mount -o bind /dev /mnt/f12/dev/
chroot /mnt/f12/ /bin/bash

then do a grub install in the chroot and then re-boot? would that work for fedora?

anyway i'm away to finish off setting up my new F12 install, much credit to the guys as this release is looking awesome so far, bar the hickups with the livecd's and raid ;)

phil

(In reply to comment #13)
> i also purchased an F12 install dvd and it arrived today and it did install
> perfectly well on the same machine, and i'm sure that with your red-hat 'hat'
> on you will be perfectly happy with this, but as for fedora the live cd's are
> the most downloaded and distributed methods of install and i really think that
> anaconda should also work with the live cd install method too.

He,

Hey I was a Fedora contributor for 5 years before I became a Red Hat employee, trust me I care about Fedora, I care a lot about Fedora. And as such I do care
about livecd installs.

So I will definitely look in to this. It may take a while though, as anaconda team we are juggling a lot of responsibilities. We currently have 150 bugs which are not even triaged yet. That is we did not even have the time to
look at them close enough to decide if they are a real bugs, and if so which team member should deal with them. At to that the bugs which do actually have some one looking into them (like this one), and we are kept quite busy.



> 
> also would it be possible to do something like make a partition to install F12
> too (eg /dev/sda1) then start the live cd and 
> 
> mkdir /mnt/f12
> mount /dev/sda1 /mnt/f12/
> cp --preserve -R /{bin,dev,home,root,usr,boot,etc,lib,opt,selinux,srv,sbin,var}
> /mnt/f12/
> mkdir /mnt/f12/{mnt,tmp,proc,sys}
> chmod 1777 /mnt/f12/tmp/
> mount -t proc proc /mnt/f12/proc/
> mount -o bind /dev /mnt/f12/dev/
> chroot /mnt/f12/ /bin/bash
> 
> then do a grub install in the chroot and then re-boot? would that work for
> fedora?
> 

Yes, that is what the livecd installer in essence does.

(In reply to comment #14) 
> He,
> 
> Hey I was a Fedora contributor for 5 years before I became a Red Hat employee,
> trust me I care about Fedora, I care a lot about Fedora. And as such I do care
> about livecd installs.
> 
> So I will definitely look in to this. It may take a while though, as anaconda
> team we are juggling a lot of responsibilities. We currently have 150 bugs
> which are not even triaged yet. That is we did not even have the time to
> look at them close enough to decide if they are a real bugs, and if so which
> team member should deal with them. At to that the bugs which do actually have
> some one looking into them (like this one), and we are kept quite busy.
> 


sorry hans i did not mean to imply that you didn't care about fedora, only that you would be happy that the install dvd worked perfectly on bios raid :). i recently joined the bugzappers group and although i'm very busy in the run up to christmas i will have more time to give to bugzapping after it passes and i will make it a point to spend some time triaging anaconda bugs to help you guys out :)

> 
> Yes, that is what the livecd installer in essence does.  
>

that is good to know, just in case i come up against a similar problem in the future, and for others with this problem you now have a solution to install F12 without having to download/purchase the install dvd ;)

phil

(In reply to comment #15)
> sorry hans i did not mean to imply that you didn't care about fedora, only that
> you would be happy that the install dvd worked perfectly on bios raid :). i
> recently joined the bugzappers group and although i'm very busy in the run up
> to christmas i will have more time to give to bugzapping after it passes and i
> will make it a point to spend some time triaging anaconda bugs to help you guys
> out :)
> 

Hi,

Note that so far anaconda has been deliberately kept out the bugzappers effort,
it is a rather special beast, and judging anaconda bugs requires a lot of anaconda specific knowledge. Also we have our own procedure, since we are a team, we have a bugzilla account for the team (just to assign to, no one ever logs in as such), and per person bz accounts. A bug is triaged for us when it
is a assigned to a personal bz account. Also see:
https://fedoraproject.org/wiki/Anaconda/BugTriage

Which is written as a place to gather information about triaging for anaconda
team members. So although I do appreciate the offer to help here, I'm not sure it is a good idea. If you want to move forward with this, please join #anaconda on freenode and for the first few bugs, discuss what you want to do with the
bug there before doing it.

Regards,

Hans

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

Getting almost exactly the same stack trace from Comment #17 when trying to install F12 on my machine (except I'm intall i686 instead of x86_64).  Using similar hardware as the user in that stack trace (NVIDIA FakeRaid).  Machine was previously running F11.

Comment #13 seems to suggest the full install disk might work, so I'll download that and give it a try.

I'll also try to upload my anaconda log file to this case as well, in case there are any additonal details in there that help.

Created attachment 376279 [details]
Anaconda traceback file

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

I'm marking this as a duplicate of bug 551790, which is tracking the same issue and where (hopefully) some progress is being made.

*** This bug has been marked as a duplicate of bug 551790 ***