The following was filed automatically by anaconda: anaconda 13.37.2 exception report Traceback (most recent call first): File "/usr/lib/anaconda/iw/cleardisks_gui.py", line 146, in getScreen self.bootDisk = sorted(names, self.anaconda.storage.compareDisks)[0] File "/usr/lib/anaconda/gui.py", line 1393, in setScreen new_screen = self.currentWindow.getScreen(anaconda) File "/usr/lib/anaconda/gui.py", line 1314, in nextClicked self.setScreen () IndexError: list index out of range
Created attachment 407748 [details] Attached traceback automatically from anaconda.
This is for an install onto a single Intel Matrix RAID10 array. There are three Windows partitions and a slightly confused picture regarding the rest of the partitions (I.e. another distribution failed to install on the free space and I haven't inspected the partition table since). Basically, after going into non-trivial disk layout, I'm offered the RAID drive at which point it all goes wrong. Best Regards Jens
Jens, Hi, looking closely at the logs it seems you were told the disk had an invalid disklabel and were asked if you wanted to re-initialize and you then clicked no. Is this correct, iow did you get a question to re-initialize the raidset and did you click no ? I believe you did and this resulted in 0 disks being available to install to, which resulted in the traceback you posted. So it seems we have 2 issues here: 1) your partition table is damaged 2) when there is only 1 "disk", and its disklabel is not recognized, and the user chooses to ignore it, we traceback. 2) is something which we can fix in anaconda. 1 is something you'll have to fix your self. Try switching to tty2 (ctrl + alt + F2) when you get the initialize disk question and then run "fdisk /dev/md127", fdisk may auto fix some things, and maybe you can see something like a clearly wrong partition which you can remove. Then choose "w" to write the fixed table (danger, back first!). Once you've hopefully fixed your disk, verify this by doing parted /dev/md127 p If that now reads the table successfully things are ok now, reboot and the next install attempt you should not get the initialize disk question. Thanks, Hans
Indeed, that is correct. It's all coming back to me... Seriously, I had been experimenting with three different distributions, and not started from scratch every time. I did indeed get a question to re-initialise and thought that it was "merely" asking me if I wanted to start from scratch so I selected "no." I tried starting from scratch with Fedora (initialised the RAID array, installed Windows, started Fedora installer and defined a mount point for a primary partition) and it worked, i.e. I got installed and can now boot. So, after fixing the problem with my partition table, the install worked. Thanks for the prompt help Best Regards Jens
Jens, Thanks for the prompt answer, that means that the only anaconda issue we have is: 2) when there is only 1 "disk", and its disklabel is not recognized, and the user chooses to ignore it, we traceback. I'll write a fix for that.
(In reply to comment #5) > Jens, > > Thanks for the prompt answer, that means that the only anaconda issue we have > is: > > 2) when there is only 1 "disk", and its disklabel is not recognized, and > the user chooses to ignore it, we traceback. > > I'll write a fix for that. Fixed in master.
Created attachment 451814 [details] Attached traceback automatically from anaconda.
Created attachment 453523 [details] Attached traceback automatically from anaconda.
I seem to just have reproduced this with the F14 Final TC 1.1 KDE i686 livecd. I think I also have an Intel Matrix RAID controller and an RAID10 is active. But I didn't get any disklabel popup that I could choose yes/no from. Instead, after I chose the specialized storage device, I was told: "Disks sda, sdb, sdc, sdd contain BIOS RAID metadata, but are not part of any recognized BIOS RAID sets. Ignoring disks sda, sdb, sdc, sdd." ...which is really weird as I just chose that very bios raid in the specialized storage device part. Also, the set was recognized in F14 Alpha/Beta. So I clicked okay on that popup (only choice) and went ahead. When trying to review the partitioning layout I got the above traceback. Weird: out of 4 tries I could only reproduce this 3 times. I think I did the very same for 4 times, though. Re-assigning/-opening this bug and adding blocker according to this (beta) test case: https://fedoraproject.org/wiki/QA:Testcase_Install_to_BIOS_RAID
Note that comment 9 is different than the original bug. With anaconda 14.19 and an uninitialized disk it does not backtrace if you choose not to initilaize the disk. It shows the dialog that hansg added, so the problem in comment 9 must be taking a different path to hit the traceback.
Reviewed at the blocker meeting of 2010/10/15. Accepted as a blocker under (Beta) criterion "The rescue mode of the installer must be able to detect and mount (read-write and read-only) LVM, encrypted, and RAID (BIOS, hardware, and software) installations ". Anaconda team to investigate. The patch for the initial issue is in the F14 tree, so current reporter must be hitting it via a different path as Brian says. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I think I have a patch for the traceback, but I don't have any experience with BIOS RAID so I do not know what potential side-effects the fix could have. Sandro reports that the patch does stop the traceback but that the install won't proceed (because there is nothing to install to). Maybe we need to open a separate bug for the BIOS RAID issue. I'd like to get hansg's input on this.
Created attachment 453762 [details] Proposed Patch
Quoting my reply to the patch on anaconda-devel list (-: This look correct to me. hidden formats are either raid or multipath members. If those are present a raid-set (which in this case counts as a disk as we're talking firmware raid here not regulat mdraid) or a multipath disk (rather then a member) should also be present. If not then indeed we have no usable disks. Ack. Regards, Hans
Created attachment 453773 [details] lsmod from livecd while installer was running
Created attachment 453774 [details] lsmod from dvd while anaconda was running
Okay, time for an update from my side after having poked a bit deeper into it and after talking about it with Brian on IRC. - I can still reproduce this in 3/4 of all tries with the LiveCD - I can NOT reproduce this at all with the DVD Therefore Brian asked me to attach the different lsmod outputs from both media which I just did. Let me make my report of how this currently runs a bit more detailed. - There's 4 disks in this system, sd{a,b,c,d} - and only those four - All are 100% consumed in the bios raid with level 10 - The bios raid storage is shown in the installer in the specialized storage tab - The bios raid storage works (there's windows on it and the dvd installer can write to it) Sequence: 1) I choose the bios raid storage from the specialized storage tab 2) I get an error msg about my single disks: "Disks sda, sdb, sdc, sdd contain BIOS RAID metadata, but are not part of any recognized BIOS RAID sets. Ignoring disks sda, sdb, sdc, sdd." 3) if I continue I'll get the traceback once I try to review the partitioning layout The fix Brian mentioned steps in AFTER 2) and shows "no disks found" which only "back" and "exit" as options, even if I chose the bios raid storage before. So while Brian's fix might fix the traceback, it doesn't solve my two problems: - error message about the single disks is shown - can't install on bios raid If there's anything more I can try kindly let me know.
The lsmod differences are largely iscsi-related, though the livecd does not have linear loaded which might be important: --- dvd 2010-10-18 12:22:13.000000000 -0400 +++ livecd 2010-10-18 12:22:19.000000000 -0400 @@ -1,35 +1,36 @@ -aes_generic +acpi_cpufreq async_memcpy async_pq async_raid6_recov async_tx async_xor cbc -cramfs +cpufreq_ondemand dm_crypt dm_multipath dm_round_robin drm drm_kms_helper -edd -exportfs -ext2 fat fcoe gf128mul i2c_algo_bit i2c_core +i2c_i801 +iTCO_vendor_support +iTCO_wdt +ip6_tables +ip6t_REJECT +ip6table_filter ipv6 -iscsi_ibft -iscsi_tcp +joydev libfc libfcoe -libiscsi -libiscsi_tcp -linear lrw +microcode mii -pcspkr +mperf +nf_conntrack_ipv6 r8169 radeon raid0 @@ -39,11 +40,26 @@ raid6_pq scsi_tgt scsi_transport_fc -scsi_transport_iscsi +serio_raw sha256_generic +snd +snd_hda_codec +snd_hda_codec_atihdmi +snd_hda_codec_realtek +snd_hda_intel +snd_hwdep +snd_page_alloc +snd_pcm +snd_seq +snd_seq_device +snd_timer +soundcore squashfs +sunrpc ttm +uinput +usb_storage vfat -xfs +xhci_hcd xor xts
Just to rule that difference out, I'd try modprobing that module before clicking on the live installer icon.
modprobe linear just before starting the installer did not change the behaviour. As agreed on today's blocker review meeting, I opened a new bug (#643967) for the remaining issues as the original problem (the traceback) was treated with a working patch. I'm not sure what the current state of that patch is, so I'll leave it to bcl or clumens to change the status of this bug accordingly.
(In reply to comment #20) > modprobe linear just before starting the installer did not change the > behaviour. > > As agreed on today's blocker review meeting, I opened a new bug (#643967) for > the remaining issues as the original problem (the traceback) was treated with a > working patch. Thanks, moving this bug to MODIFIED. This should be picked up by anaconda-14.21-1 which will be available shortly. As you note above, we can track the remaining BIOS RAID issue as bug#643967.
anaconda-14.21-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/anaconda-14.21-1.fc14
anaconda-14.21-1.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update anaconda'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/anaconda-14.21-1.fc14
anaconda-14.21-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
Created attachment 482178 [details] Attached traceback automatically from anaconda.
Created attachment 516188 [details] Attached traceback automatically from anaconda.
Created attachment 517011 [details] Attached traceback automatically from anaconda.