Bug 663294
Description
Eric Springer
2010-12-15 10:23:35 UTC
Created attachment 468827 [details]
Attached traceback automatically from anaconda.
Created attachment 468833 [details]
Attached traceback automatically from anaconda.
This should be fixed in the next build of anaconda. Created attachment 469513 [details]
Attached traceback automatically from anaconda.
Created attachment 469517 [details]
Attached traceback automatically from anaconda.
Comment 5(In reply to comment #5) > Created attachment 469517 [details] > Attached traceback automatically from anaconda. This happened with the most recent anaconda, in the livecd: http://alt.fedoraproject.org/pub/alt/nightly-composes/xfce/ http://alt.fedoraproject.org/pub/alt/nightly-composes/xfce/logs/20101217.16-i386.log http://koji.fedoraproject.org/koji/buildinfo?buildID=209270 Created attachment 470472 [details]
Attached traceback automatically from anaconda.
It now throws the new error, but we need to track down why. I don't see this with the nightly build desktop-x86_64-20101222.15.iso I saw it on my local compose of a rawhide cd which may not be the same. (In reply to comment #9) > I don't see this with the nightly build desktop-x86_64-20101222.15.iso > > I saw it on my local compose of a rawhide cd which may not be the same. Cancel that, I've now seen it with the nightly as well. But not consistently. Created attachment 470618 [details]
Attached traceback automatically from anaconda.
(In reply to comment #11) > Created attachment 470618 [details] > Attached traceback automatically from anaconda. This is trying to install onto a KVM 31gb unallocated guest space. (F14 Host) So have tried nightlies with both pre-existing partitions, and no partitions. Same result. But /usr/bin/liveinst will not start from desktop icon for me. has to be started from Terminal, and only then after I run "rm -rf /var/log" # /usr/bin/liveinst Traceback (most recent call last): File "/usr/sbin/anaconda", line 535, in <module> os.mkdir("/var/log", 0755) OSError: [Errno 17] File exists: '/var/log' Have got it installed eventually. Do above then run install second time, install goes ahead, but with a new window every time next is clicked. Will attach a screencap. Will not crop, so size can be seen. Created attachment 470620 [details]
Device Selection
Scrollbars make it awkward.
Created attachment 470668 [details]
liveinst crash
Saved locally and c&p into textfile.
Created attachment 474066 [details]
Attached traceback automatically from anaconda.
Created attachment 474257 [details]
Attached traceback automatically from anaconda.
Created attachment 474771 [details]
Attached traceback automatically from anaconda.
Created attachment 474808 [details]
Attached traceback automatically from anaconda.
Created attachment 475943 [details]
Attached traceback automatically from anaconda.
Created attachment 478383 [details]
Attached traceback automatically from anaconda.
Created attachment 478562 [details]
Attached traceback automatically from anaconda.
Created attachment 478662 [details]
Attached traceback automatically from anaconda.
Created attachment 478737 [details]
Attached traceback automatically from anaconda.
Created attachment 479537 [details]
Attached traceback automatically from anaconda.
(In reply to comment #24) > Created attachment 479537 [details] > Attached traceback automatically from anaconda. Discovered after building and testing a live image with the latest F15Alpha kernel Can you reproduce it consistently? (In reply to comment #26) > Can you reproduce it consistently? Seems so (3/3), in my virt guest. Note, I'm slightly confused since all attached tracebacks since your first one (2010-12-23) are different from the originally reported issue. anaconda 15.20 exception report Traceback (most recent call first): File "/usr/lib64/python2.7/site-packages/pyanaconda/iw/account_gui.py", line 91, in setCapsLockLabel if _isys.isCapsLockEnabled(): File "/usr/lib64/python2.7/site-packages/pyanaconda/iw/account_gui.py", line 72, in getScreen self.setCapsLockLabel() File "/usr/lib64/python2.7/site-packages/pyanaconda/gui.py", line 1338, in setScreen new_screen = self.currentWindow.getScreen(anaconda) File "/usr/lib64/python2.7/site-packages/pyanaconda/gui.py", line 1258, in nextClicked self.setScreen () RuntimeError: XOpenDisplay failed Should we continue tracking XOpenDisplay here? (In reply to comment #27) > (In reply to comment #26) > Should we continue tracking XOpenDisplay here? Nm ... the tracebacks aren't as different as I originally thought. They appear to be same, with changes in lineno's and the final exception string Adding to F15Alpha for discussion as an Alpha release blocker per the following criteria [1]: "The installer must boot (if appropriate) and run on all primary architectures from default live image, DVD, and boot.iso install media" https://fedoraproject.org/wiki/Fedora_15_Alpha_Release_Criteria If this happens only to some, and we have a workaround, that might lower the priority of the issue. So far, I seem to keep hitting this issue. Interested in feedback from other testers. It could be how I built the live image. Per 2011-02-18 Alpha Blocker meeting: Need more information to determine if this problem is widespread. #agreed 663294 - Needs more testing to determine scope of problem. Leave on proposed blocker list pending more information. New nightly live .iso's expected later today. Created attachment 479733 [details]
Attached traceback automatically from anaconda.
Created attachment 479738 [details]
Attached traceback automatically from anaconda.
Created attachment 479803 [details]
Attached traceback automatically from anaconda.
*** Bug 678930 has been marked as a duplicate of this bug. *** Created attachment 479889 [details]
Attached traceback automatically from anaconda.
I can still reproduce this with the latest nightly (kde-1g-x86_64-20110221.00.iso). Reproduced on a Dell Optiplex 755 - which is in the top 10 HW models according to smolt stats, and actually #2 non-VM, non-unnamed model. Not sure what the criteria for 'being widespread' are but I sure think this should be accepted as a blocker. Created attachment 479912 [details]
Attached traceback automatically from anaconda.
(In reply to comment #30) > Per 2011-02-18 Alpha Blocker meeting: > > Need more information to determine if this problem is widespread. > > #agreed 663294 - Needs more testing to determine scope of problem. Leave on > proposed blocker list pending more information. It appears to still be an issue, and we are seeing enough people reproduce this issue. I'd like to move this from the "ProposedBlocker" list to the "AcceptedBlocker". This issue appears to be preventing all/most live image installs which is an Alpha criteria blocker. https://fedoraproject.org/wiki/Fedora_15_Alpha_Release_Criteria While #anaconda is already working on resolving this issue let me add what's been found that might influence whether this is to become a blocker. The bug won't show up: - if the hostname is not changed (i.e. localhost.localdomain) OR - if one performs 'xhost +' before launching anaconda It should be discussed whether either is considered a valid workaround for the alpha release. is this bug present if hostname is obtain via dhcp ? Yes, if the hostname is automatically obtained, the bug will be hit. Changing it manually to localhost.localdomain will help, though. Created attachment 479957 [details]
Attached traceback automatically from anaconda.
This happens because the hostname was changed. In the live install X is running with auth enabled, so changing the hostname causes the X auth to fail when it tries to check the capslock state. During a normal install X is run with the -ac command line option so this isn't an issue. The fix is to disable auth in the liveinst script. i was able to reproduce and agree it is a blocker. i tested that the proposed fix on the anaconda list works as well i was able to reproduce and agree it is a blocker. i tested that the proposed fix on the anaconda list works as well (In reply to comment #45) > i was able to reproduce and agree it is a blocker. i tested that the proposed > fix on the anaconda list works as well Thanks Dennis! I also have confirmation from clumens on IRC as well that this is a blocker. > clumens: jlaska: 663294 definitely is Adding whiteboard: ApprovedBlocker. (In reply to comment #46) > Adding whiteboard: ApprovedBlocker. Apologies, make that 'AcceptedBlocker' anaconda-15.20.1-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/anaconda-15.20.1-1.fc15 anaconda-15.20.1-1.fc15 has been pushed to the Fedora 15 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-15.20.1-1.fc15 Confirmed fix with anaconda-15.20.1-1.fc15 (RC1) Can't confirm fix with Alpha RC1 KDE (anaconda-15.20.1-1.fc15.x86_64). On a freshly booted system: $ liveinst No protocol specified xhost: unable to open display ":0" 14:28:44 Starting graphical installation. No protocol specified 14:28:44 Exception starting GUI installer: could not open display 14:28:44 GUI installer startup failed, falling back to text mode. So the patch actually made things worse :) No idea why liveinst fails to perform the xhost command though, as I can run it manually: $ xhost access control enabled, only authorized clients can connect SI:localuser:liveuser $ xhost + access control disabled, clients can connect from any host I haven't tried any other Live iso yet. Confirmed Sandro's behavior on the KDE RC1 live images. On 2 of 6 boot attempts, running liveinst starts the graphical installer. The 4 other attempts, running liveinst fails to start the graphical installer, and launches the text-mode installer. If you are clicking on the desktop icon to start liveinst, you'll never see the text-mode installer. Running the following before starting liveinst works # xhost + In the 4 failure attempts, it seems that the XAUTHORITY ENV variable isn't being passed to the root user. I think this means the root user won't be able to connect to the liveinst X session. In the 2 successful attempts, when I `su` to root, I see an XAUTHORITY ENV variable. So far, I've not managed to reproduce this failure on the GNOME live image. If this doesn't impact the GNOME image, we may want to track this as a different bug report, and leave this issue in VERIFIED (as the original problem has been addressed). I'm moving this KDE problem out into a new bugzilla since the issue is different enough from the originally reported problem addressed here. That bug is bug#679486. Created attachment 480583 [details]
Attached traceback automatically from anaconda.
Created attachment 480620 [details]
Attached traceback automatically from anaconda.
Due to the problem with GNOME LiveCD (see comments for GFX Test Day: https://fedoraproject.org/wiki/Test_Day:2011-02-23_Radeon ) it is not possible to do HDD isntall from GNOME Live CD. GNOME doens't start, crash in mutter. See also Bug 677842 https://bugzilla.redhat.com/show_bug.cgi?id=677842 So I downloaded and booted from KDE LiveCD. And tried to isnatll Fedora 15 from it. Got problem - see attachment above. I had blank screen, when tried to press next - it was saying "you need to define password for root" There was no form for root password on screen. Very confusing. Created attachment 480727 [details]
Attached traceback automatically from anaconda.
v.plessky, you are using an older version of anaconda. This bug is fixed in 15.21-1 and you have 15.20-1 on the iso's you are using. anaconda-15.20.1-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report. Created attachment 481102 [details]
Attached traceback automatically from anaconda.
*** Bug 694961 has been marked as a duplicate of this bug. *** *** Bug 693806 has been marked as a duplicate of this bug. *** |