Red Hat Bugzilla – Bug 491160
anaconda 188.8.131.52 rawhide install traceback failures
Last modified: 2009-03-26 14:45:59 EDT
Created attachment 335885 [details]
Description of problem:
Installing rawhide of 22090319 using boot.iso and askmethod, got tracebacks on two attempts
Version-Release number of selected component (if applicable):
Every time for 2 times, different tracebacks.
Steps to Reproduce:
1. get boot.iso from mirror.cc.vt.edu
2. boot cd and use askmethod and enter url
3. first attempt, provided passphrases for two encrypted volumes
4. selected custom configuration and after specifying configuration clicked next and got first traceback.
5. reboot and cancel out of passphrase dialogues, again selected custom config and got traceback after specifying config and clicking next
system is a test system ASUS P5K-E mobo with sata and ide drives configured both standard ext3 and LVs and a win vista partition. Root partition for rawhide was on an ext4 LV.
Created attachment 335887 [details]
second traceback (cancel out of passphrase dialogues)
preformatted boot and / and retried first attempt and got same error, except different lv: LVMError: lvdeactivate failed for fc10.
wow, and I thought I had lots of HD :). I have committed some code yesterday that takes care of preexisting inconsistent lvms. Coule you pls test with anaconda-184.108.40.206-1.
Yeh, lots of drives--I test Fedora (have 8 to 11a and rawhide, i386 and x64), suse, mandriva, slack, gentoo, ubuntu, debian, xos, and etc.), and keep boot parts separate.
I tried to test 34-1, but even tho the pkg dir and image dir of the mirrors say 20 Mar and anaconda 34-1, the install image anaconda says 33, so I aborted.
Would anaconda 34 not have made it into the install image?
I am going to try anyway while waiting response.
OK, tried the install.img dated 20 March even tho anaconda said it was version -33. Tried first scenario--provided passphrases for encrypt. partitions and was able to get thru software selection but got traceback error: RuntimeError: dictionary changed size during iteration. traceback in next commit. So, reran and cancelled out of pass phrase dialogues and this time total hang after clicking next after software selection--no traceback.
Note: compared to Fedora 11 alpha, this installer is magnitudes slower wrt paritioning tasks. Wait time leaving a partition edit dialogue is up to two minutes before the partitioner returns. Doesn't make any difference if editing a plain vanilla ext3 parition or ext4 LV. Just dog slow.
Created attachment 336138 [details]
traceback from install.img of 20 March 21009
Created attachment 336176 [details]
21 March traceback after entering crypt passphrases
Assuming the install.img dated 21 March contained the -35 version of anaconda, same problem exists both with and without entering pass phrases for encrypted partitions. Traceback occurred in test one after clicking ok after entering the pass phrase for the second encrypted partition. Took 50 seconds before failure reported. In test two, 55 seconds after clicking cancel/ok for second ncrypted partition.
So, just repeated original scenario (entered pass phrases for encrypted partitions) but used Fedora 11 Alpha i386 DVD and install was smooth and fast.
I think this bz should be a blocker.
We're not really worried about speed and UI problems right now - more interested in getting the code correct. Your latest traceback is still reporting itself as 220.127.116.11, which is old. The current release is 18.104.22.168 which should be tagged into the rawhide tree. Can you please verify that your mirror contains the right anaconda package in os/Packages and assuming so, test your original bug report from that tree? I'd like to use one bug report to track one individual problem so if your original problem is fixed, we can close this out and deal with other problems in other reports. Thanks.
I verified the correct anaconda package in the i386/os/Packages dir in the mirror before testing and also verified that the date of the install image was current. I also tried with another mirror which had the correct package. Mirrors tried were VT and Duke. In looking at the mirrors now, I see the -35 version and an install image now dated 23 March. When I did the test on 21 March, the install image was dated 21 March. So...will test once more.
Created attachment 336403 [details]
23 March traceback after entering crypt passphrases
Same problem as on 21 March. install.img on mirror (mirror.cc.vt.edu) dated 23 March and anaconda version in Packages dir was -35 while -33 reported during install attempt. Will add program.log in next attachment.
Created attachment 336404 [details]
23 March traceback program.log after entering crypt passphrases
Created attachment 336469 [details]
24 March traceback after entering crypt passphrases
Using mirror.cc.vt.edu with install.img dated 24 March and anaconda version 36 in Packages directory, same error occurred after entering pass phrases for encrypted file systems. Program.log will also be attached.
FWIW, deleted 3 LVs, reran test, same failure.
Created attachment 336470 [details]
24 March traceback program.log after entering crypt passphrases
You definitely have a problem with your mirrors, then, because you are not getting an updated install.img. I have had multiple people here verify that the install.img they are using reports the correct version when starting up, and today that version is .37. I'm not sure what's going on here. I wonder if you could try using the install.img from download.fedora.redhat.com?
Created attachment 336677 [details]
25 March traceback after entering crypt passphrases
Verified dates of install.img file and anaconda version (-37) on mirror.cc.vt.edu and tried again with same failure as before. Traceback attached and program.log next with further comments/observations.
Created attachment 336718 [details]
25 March traceback from download.fedora.redhat.com
I didn't see the comment about using download.fedora.redhat.com. However, same failure occurs, BUT anaconda reports as version -37. program.log coming next. I am deleting attachment 336677 [details] which was from the questionable mirror.
Created attachment 336719 [details]
25 March traceback program.log from download.fedora.redhat.com
I am going to do some more testing at a time when download.fedora.redhat.com is less congested. I am going to vary the starting state of the computer, i.e., software reboot from rawhide into boot.iso, reset button reboot into boot.iso and cold iron restart into boot.iso. In the past I have seen installations vary somewhat depending on the starting state.
Created attachment 336741 [details]
25 March cold iron traceback
this traceback is different from the previous in that the installer got to the custom partitioning screens and it is: "TypeError: argument of type 'NoneType' is not iterable." after selecting the boot partition. Again used download.fedora.redhat.com and anaconda reported it was -37 version.
I believe this is related even tho it is a different error msg.
Out of time to do other tests tonight.
Success at last with anaconda version -38.
HOWEVER, please note: anaconda (I think) sat for between 40-45 minutes after selecting software to install before installation began. I had seen this earlier and killed the install after about 15-20 minutes of no activity, assuming there was a problem. I installed twice just to verify you had to wait 40-45 minutes for the install to start.
Do you want a separate bz for the inordinate wait time?
Also, partition labels are being deleted. They should not be, or the user should be asked.
Otherwise, this bz can be closed as fixed rawhide.
Thank you for your patience with me.
Glad it's working now. We're aware of the speed issues, so don't worry about filing a bug for that. In general, we do like one bug for each issue so we can tell when things are really fixed and when they crop back up. Thanks for your testing.