Red Hat Bugzilla – Bug 588938
Hang on FC13 install with Acer Ferrari One 200 Netbook
Last modified: 2018-04-11 06:10:49 EDT
Description of problem:
Acer Ferrari One 200 netbook hangs on install of FC13 DVD ISO.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Install Fedora from DVD
2.On first boot (and all subsequent boots) Fedora freezes
On boot, it switches to graphical mode and freezes.
I tired setting debug=1 and level=3 but I always switch into
graphical mode. This means I don't have any useful debug info
to share. If someone has a command line I should be using
I will try that instead to get more debug info.
I can't seem to get the system to single step through the
boot process either so I am not even sure what the last line is
that is printed before it switches to graphical mode.
I have not gone through the part of the install where you create
the first user account.
The first part of the graphical installer work just fine. It was
not until the first reboot (where you would create the first user
account did I get the hang).
This Acer has a funky new PCI thing on the side. It is not an
express slot. It is designed for an external graphics card. This
may be a problem.
I have same machine. and it occurred same problem.
I tried to install only base package group without X. It was successful.
I did a minimal install from the DVD. When the install completed I still lock up on the initial boot.
I added debug=1 and level=3 to the command line, but I switched to the screen where the three colored bars progress along the bottom of the screen.
I then tried rebooting with rhgb removed from the command line, but debug=1 and level=3 turned on. the last lines I see printed on the screen are:
dracut: starting plymouth daemon
dracut: rd_NO_DM removing DM RAID activation
dracut: rd_NO_MD removing MD RAID activation
How do I need to disable X?
I found work around kernel option. "nomodeset 3"
After system booted, Please change /etc/X11/xorg.conf.
Created attachment 412839 [details]
my xorg.conf file for Ferrari One 200 Wide Resolution
I checked that I could boot with the nomodeset. It worked fine.
As I had the minimal install, I did not have X installed. I will redo the full install today and check everything is working.
Do I need to use another command line option at boot to stop it from using X the first time it boots?
Once installed please boot with:
And save full dmesg and attach it here along with lspci -v output (full output)
Created attachment 422454 [details]
lspci -v (via boot from installatiom media)
using boot option drm.debug=15
Please also attach the full dmesg.
Created attachment 422482 [details]
Additional information, kernel cmdline options are
ro root=/dev/mapper/vg_ferrari-lv_root rd_LVM_LV=vg_ferrari/lv_root rd_LVM_LV=vg_ferrari/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb quiet nomodeset drm.debug=15
Ok, sorry i wasn't clear attach output of command:
dmesg > acerdmesg.txt
When booting without nomodeset but with drm.debug=15 3
> When booting without nomodeset but with drm.debug=15 3
It can't boot and it freezed.
Follow this procedure :
Boot with drm.debug=15 3 radeon.modeset=0
Login as root remotely through ssh do:
tail -f /var/log/messages
Login as root a second time remotely through ssh do:
modprobe radeon modeset=1
It should allow you to capture kernel message while loading radeon with modesetting, if system is not freeze then please attach full /var/log/messages
Created attachment 425903 [details]
before modprobe -r radeon and modprobe radeon
I tried it.
Created attachment 425904 [details]
after modprobe -r radeon and modprobe radeon
This bug fixed kernel-188.8.131.52-54.fc13.x86_64 and plymouth-0.8.2-3.fc13.x86_64
Reporter, do you agree with comment 16? Is the issue fixed in kernel-184.108.40.206-54.fc13.x86_64 and plymouth-0.8.2-3.fc13.x86_64?
What is the best way for me to test this? In other words how do I create a live CD with kernel-220.127.116.11-54.fc13.x86_64 and plymouth-0.8.2-3.fc13.x86_64 to try with?
Are you able to reproduce the behaviour if you start startx command in the runlevel 3 (add 3 on the kernel command line and eliminate if you have nomodeset there)?
If yes, fresh version of logs (and output of dmesg) would be helpful.
Just to be clear
1) I should download the latest liveCD image,
2) before booting it I should change the command line for booting the kernel.
a) I should remove the nomodeset if it is on the command line
b) I should add "runlevel 3" to the command line
Is this correct?
(In reply to comment #20)
> Just to be clear
> 1) I should download the latest liveCD image,
> 2) before booting it I should change the command line for booting the kernel.
> a) I should remove the nomodeset if it is on the command line
> b) I should add "runlevel 3" to the command line
> Is this correct?
I am sorry, I should be more thorough (after this is about the released Fedora, not Rawhide). So, let me comment on your steps.
1) no, if you are able to install with your current CD by any means (in text mode, with nomodeset, whatever), just do it.
2) then make sure in /etc/grub.conf that line saying "hiddenmenu" is commented out (by putting # to the beginning of the line) and timeout is something reasonable (5 or so, the number means number of seconds before the default option ... from the option default ... is used).
4) in the grub menu press either [TAB] or [A], whatever gets you to edit the kernel command line and remove the word "nomodeset" (if it is there), and add
5) you will get to the text console, login as root
6) check that there is no /etc/X11/xorg.conf (move it somewhere else, gzip it, rename it to something very different)
7) back to the text console, login as normal user (not root)
8) run startx
9) it really doesn't matter whether you will get something sensible, just blank graphic display background, or whether Xorg crashes altogether.
10) Just run dmesg >dmesg.out and then attach it together with
* X server log file (/var/log/Xorg.*.log), and
* system log (/var/log/messages)
to this bug as separate uncompressed attachments.
I will take a look to make sure we know we have everything we need.
Thank you very much for helping Fedora to shine!
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13. 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 '13'.
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 13'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 13 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 please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
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.
The process we are following is described here:
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 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.