Red Hat Bugzilla – Bug 802026
installation freeze right after launching anaconda graphical install
Last modified: 2013-07-31 17:46:36 EDT
Description of problem:
Installed F17 alpha (network install image). Text mode ok. Then anaconda started graphical install. The graphics froze within a second. Mouse cursor was moving, but the system did not react otherwise. Had to hard reset.
Due to system freeze in the initial stage of the installation, I was unable to recover any logs. But I strongly believe that this bug is a manifestation of Bug#742657 nouveau deadlock. All visible symptoms were the same.
Version-Release number of selected component (if applicable):
Fedora 17 alpha
Steps to Reproduce:
1. Launch the installation of Fedora 17 alpha
2. Use the graphical install (default)
3. Experience the freeze.
Unable to install. System frozen.
I have found good description of the symptoms also at https://bugzilla.novell.com/show_bug.cgi?id=597078#c Comment 63.
Proposing as blocking for F17 beta.
Note that installation process of F15 and F16 were OK on the same hardware.
Please consider this bug as an Fedora 17 Beta release blocker. It impacts the release criterion that:
(Fedora 17 Alpha Release Criteria)
9. The installer must be able to complete an installation using the text, graphical and VNC installation interfaces.
[ĵust learnt about bureaucracy related to blocker bugs so adding formal request]
As described, this is a hardware-dependent issue: please note we usually do not take single-system hardware-related crashes as blocker bugs (or else we'd never release anything).
Is this reliably reproducible (it happens every time you try and install Fedora)?
Does it happen if you try to boot the live image?
Does it happen also with Beta TC1 - http://dl.fedoraproject.org/pub/alt/stage/17-Beta.TC1/ ?
Fedora Bugzappers volunteer triage team
Thanks for your response. Please find the requested info below.
For me it is a show stopper, not only for F17, but F16 is having the issue too from some update (F16 installer was working OK back then). F15 runs without problems, but nearing EOL.
NVIDIA GTX580 is the suspect
Is this reliably reproducible (it happens every time you try and install
Yes, every time,
within a split of a second after graphical installer pops in. I did not even get the chance to click on the first dialog box with the warning about prerelease version.
Does it happen if you try to boot the live image?
Tried KDE live image from beta TC1: KDE almost started, but got frozen immediately. The icons that are shown during the KDE start were left on the screen. The device manager popup from tray was shown in the corner partially dimmed. The system was frozen except for the mouse pointer moving freely.
Does it happen also with Beta TC1
The above reflects to beta TC1.
My best guess is:
F15 had no acceleration for these chipsets at all, F16 didn't initially but I guess a kernel update may have fixed that.
And for whatever reason, it doesn't appear to work on your card. I need more information to even begin to figure this out, kernel logs from after the hang would be most useful (even if you have to install in text mode and re-enable nouveau after to get them). Generally, the cards of the generation that yours is do work fine (I have several on my desk that all work), you get unlucky :(
Another alternative is to pass "nouveau.noaccel=1" in your kernel options when installing, which should also work around the issue hopefully.
Created attachment 570115 [details]
boot into runlevel 1 first
then changed to runlevel 5
Ben, you have guessed right. I have used "nouveau.noaccel=1" with Live DVD and then with network install DVD and there was no hangup. Worked like a charm. Thanks, I really appreciate that.
Then I boot with nouveau acceleration and recorded log of the freeze, will attach shortly. Just an excerpt around the freeze:
Mar 14 22:11:00 localhost kernel: [ 170.667522] [drm] nouveau 0000:01:00.0: PFIFO: read fault at 0x00080da000 [PAGE_SYSTEM_ONLY] from PGRAPH/GPC3/(unknown enum 0x0000000b) on channel 0x00011c1000
Mar 14 22:11:00 localhost kernel: [ 170.667527] [drm] nouveau 0000:01:00.0: PFIFO: unknown status 0x40000000
Mar 14 22:11:13 localhost kernel: [ 183.005735] [drm] nouveau 0000:01:00.0: GPU lockup - switching to software fbcon
In case you need more info or do some test, just let me know. Seems like my system is eager to replicate the issue on every occasion.
Adam, I no longer think this is a Beta blocker issue.
Workaround is very simple to use, but maybe not that simple to figure out.
Do you think, until a solution is found, the issue could be listed among "Known issues" to save other possible unlucky souls from having a headache ?
Anyway, thanks guys for not letting me down :-)
Fedora Bugzappers volunteer triage team
Freezes immediately after the gnome shell loads. Using the boot param "nouveau.noaccel=1" helps.
My Smolt profile,
This bug is appearing on the F17 Common Bugs page
However the /etc/modprobe.conf/noaccel.conf permanent fix doesn't work for me.
I had to add "nouveau.noaccel=1" as a kernel param in /etc/default/grub and run:
$ grub2-mkconfig -o /etc/grub2.cfg
(In reply to comment #11)
> $ grub2-mkconfig -o /etc/grub2.cfg
Correction. That should be,
$ grub2-mkconfig -o /boot/grub2/grub.cfg
And to fix what calling the incorrect cmd above did,
$ rm /etc/grub2.cfg
$ ln -s /boot/grub2/grub.cfg /etc/grub2.cfg
PLEASE NOTE: the Common Bugs entry mentions only the GTX 580, but I hit this bug with the GT 240. Same bug, same workaround.
Could the Common Bugs page please be updated accordingly?
It has an edit button, so, yes...
The Common Bugs page isn't world-editable.
The page itself suggests, if you find a new bug: "Add it yourself, if you have wiki access." The implication is that most of us don't; and indeed, I don't see any edit button.
So I need someone who does have edit permissions to change the entry.
All you need for that is a Fedora account - https://admin.fedoraproject.org/accounts/
I have a GTX 550, I tried installing from the Fedora 17 x86_64 DVD and I get the hang. Adding nouveau.noaccel=1 to the kernel boot line does not fix the issue -- still hangs when trying to install. I never see the graphical screen. Are there any other kernel options needed to get this to install?
solved: you need to add "nomodeset" to the line as well. Then the installation will proceed.
I have the same issue on my GTX570HD. Although I got through the install without an issue. But I cant boot after the install because of this.
Reproduced on NVIDIA GeForce GTX 550 Ti as well with preupgrade (F16->F17). Preupgrade has started, but I got a blank screen. Since I see disk activity, I understand that the upgrade is in progress, but there is no display. I am very relactant to interrupt the upgrade and cause any harm on the system.
I will for an hour to finish by itself. If I remember well, the preupgrade does not need any confirmation to proceed after the reboot and it also performs auto-reboot. Fingers crossed!
So, for the 2nd computer which has identical hardware I have to use nomodeset and nouveau.noaccel=1 before rebooting if I understood well?
Just to add that preupgrade finished successfully and delivered a F17 healthy system. I just only didn't have any display. It did all the work alone.
(In reply to comment #20)
> So, for the 2nd computer which has identical hardware I have to use
> nomodeset and nouveau.noaccel=1 before rebooting if I understood well?
I confirm that it worked fine on the 2nd computer with exactly the same hardware. Preupgrade anaconda installer was live and kicking on the screen.
Common F17 Bugs suggestion:
1. It should include the rest of the models of NVIDIA that have isssues. It is not only GTX 580.
2. The "nomodeset" might also needed. I haven't verified that, since I wouldn't like to expirement with preupgrade stuff, but Zingale has confirmed that in comment 18.
3. No need to make anything permanent. The newer kernels are NVIDIA friendly. It works fine after 3.4 versions I think. It affected only version 3.2 and 3.3.
My workaround in comment #11 doesn't work using a 3.5.x kernel so far.
Luckily I still have a 3.4.x kernel in grub to choose to boot with.
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '17'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 17's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 17 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged change the
'version' to a later Fedora version prior to Fedora 17's end of life.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.