Bug 810888

Moving to xorg-x11-server for further triage

I'd suspect the driver before the server here.

Reporter: please boot the live image into runlevel 3 (append '3' to the kernel command line), find the IP address of the machine with ifconfig, ssh in, and then launch X with 'systemctl start prefdm.service'.  When you do this, what happens?  Does the machine lock entirely?  Can you get /var/log/Xorg.0.log?

- I appended '3' to the kernel command line....
- The 'F' loading graphic completely loads....
- Command line pops up with 'localhost login:'....
- 1 second later everything goes BLACK and LOCKS up(no chance to login)....

I just downloaded and tried Fedora 17-Beta.RC4/Live/x86_64 Live-Desktop/xfce....  Still NO GO....

Instead of the x-server, or the ati-driver - could a power management program be kicking in 1 second after boot be putting my screen to permanent sleep????  That is the only other idea I have....

Still NO GO with Fedora 17-Beta.RC4.1/Live/x86_64 Live-Desktop/xfce....

Still NO GO with Fedora 17-Nightly-20120423.09-x86_64-Live-desktop....  I hate to point out the obvious but - Final Change Deadline is in 2 weeks....  Is anyone working on this apparent AMD problem????  If not fixed Fedora 17 may be an intel only release....

Still NO GO with Fedora 17-Nightly-20120503.09-x86_64-Live-xfce....

(In reply to comment #7)
> Still NO GO with Fedora 17-Nightly-20120423.09-x86_64-Live-desktop....  I
> hate to point out the obvious but - Final Change Deadline is in 2 weeks.... 
> Is anyone working on this apparent AMD problem????  If not fixed Fedora 17
> may be an intel only release....

That _your_ radeon doesn't work is by no means an indication that zero radeons work.

If you boot with 'nomodeset' on the kernel command line you should be able to discover what IP address the machine will receive after booting.  Afterwards you should be able to boot without 'nomodeset' and ssh into the machine even after the screen goes blank.

(In reply to comment #9)
> (In reply to comment #7)
> > Still NO GO with Fedora 17-Nightly-20120423.09-x86_64-Live-desktop....  I
> > hate to point out the obvious but - Final Change Deadline is in 2 weeks.... 
> > Is anyone working on this apparent AMD problem????  If not fixed Fedora 17
> > may be an intel only release....
> 
> That _your_ radeon doesn't work is by no means an indication that zero
> radeons work.

I was just trying to get someones attention with the intel only comment....  I feel like I have been talking to myself on this thread....  But I do wonder how many people are having this problem....  I don't even know if it is indeed a radeon problem....  could be power management is kicking on and getting stuck(or something else weird)....

> 
> If you boot with 'nomodeset' on the kernel command line you should be able
> to discover what IP address the machine will receive after booting. 
> Afterwards you should be able to boot without 'nomodeset' and ssh into the
> machine even after the screen goes blank.

I am not sure how you want me to get the ip address????  I doesn't matter what params I boot up with '3' or 'nomodeset'; without 'quiet' 'rhgboot' the screen still goes black and locks 1 second after boot....  am I supposed to see the numbers go across the screen real quick when it is booting????  because I am never going to be able to type anything like 'ifconfig' to get them....

please clearify....

I just tried to do a 'preupgrade-cli' from fedora 16 to 17, just to see if it was a 'live' problem, and not a fedora 17 problem....

I get the same result - so it is a fedora 17 problem in general....  When it reboots after the fedora 17 files are downloaded it locks up and goes black 1 second after boot....  There is no way to type anything or finish the upgrade....

Does this help you identify the problem at all????  Does fedora 17 use a different ati graphic driver????

**** I Found The Bug ****
After not being able to get F17 to work from the live cd, and trying different ways to upgrade to F17 from F16 - I had to reinstall F16 from scratch....  I did that and my system worked fine....  Then I upgraded the F16 kernel from 3.1.0 to 3.3.7 and the system would not boot JUST LIKE MY F17 PROBLEMS?!?!  This was strange, because I never had any F16 problems, and now it was acting like F17?!?!

To make a long story short the problem is with the 'kernel' and 'Broadcom BCM 4313' wireless card.... You have to 'yum install akmod-wl' befora installing kernel 3.2 or 3.3....  Or you can't get the system to boot!!!!

Around kernel 3.2 I heard they tried to build 'Broadcom BCM 4313' wireless into the kernel, but It was never done properly....  If you look back at my first comments Fedora nightlys stopped working for my at the end of January, around when kernel 3.2 came out....

Until this bug in the kernel is found no one will be able to boot F17 or F18 etc. - if they have a 'Broadcom BCM 4313' wireless card(and probably other close Broadcom models)....

I hope I explained this properly....  I am 100% sure about this....

**** please pass me over to someone in charge of 'Kernel Bugs' or 'Broadcom wireless' ****

For starters, can we see the output of 'lspci -n'?

(In reply to comment #13)
> For starters, can we see the output of 'lspci -n'?

[root@localhost garypn]# lspci -n
00:00.0 0600: 1022:9601
00:01.0 0604: 1022:9602
00:05.0 0604: 1022:9605
00:06.0 0604: 1022:9606
00:0a.0 0604: 1022:9609
00:11.0 0106: 1002:4391
00:12.0 0c03: 1002:4397
00:12.2 0c03: 1002:4396
00:13.0 0c03: 1002:4397
00:13.2 0c03: 1002:4396
00:14.0 0c05: 1002:4385 (rev 42)
00:14.2 0403: 1002:4383 (rev 40)
00:14.3 0601: 1002:439d (rev 40)
00:14.4 0604: 1002:4384 (rev 40)
00:14.5 0c03: 1002:4399
00:16.0 0c03: 1002:4397
00:16.2 0c03: 1002:4396
00:18.0 0600: 1022:1200
00:18.1 0600: 1022:1201
00:18.2 0600: 1022:1202
00:18.3 0600: 1022:1203
00:18.4 0600: 1022:1204
01:05.0 0300: 1002:9712
01:05.1 0403: 1002:970f
02:00.0 0280: 14e4:4727 (rev 01)
03:00.0 0200: 10ec:8136 (rev 05)
04:00.0 ff00: 10ec:5209 (rev 01)

Would you be able to setup a wired connection for capturing netconsole output?  Or possibly a serial console?

(In reply to comment #15)
> Would you be able to setup a wired connection for capturing netconsole
> output?  Or possibly a serial console?

I just googled 'netconsole' - If I understand correctly, my system can be configued(hopefully easily) to send debugging info to another computer on the internet?  Is that correct?

hold my hand and tell me what to do, and I will give it a whirl....

Can you provide the kernel config which has the boot problem?

Created attachment 589252 [details]
/usr/src/kernels/3.3.7-1.fc16.x86_64/.config file

/usr/src/kernels/3.3.7-1.fc16.x86_64/.config file with the system working with akmod-wl....

I have the same problem on my Acer Travelmate TimelineX.

Both preupgrade and the Fedora 17 live iso stop booting right after loading the NetworkManager.
So I have no way to upgrade at the moment ...

Fedora 16 (with kmod-wl from RPMFusion) works fine.

Other than the original poster, in my case it's a x86-installation (on x64-hardware).

(In reply to comment #19)
> I have the same problem on my Acer Travelmate TimelineX.
> 
> Both preupgrade and the Fedora 17 live iso stop booting right after loading
> the NetworkManager.
> So I have no way to upgrade at the moment ...
> 
> Fedora 16 (with kmod-wl from RPMFusion) works fine.
> 
> Other than the original poster, in my case it's a x86-installation (on
> x64-hardware).

I just wanted to thank you for the backing me up on this....

As additional information:

My specific Laptop Model is a "TM8172T" and the wireless Card is (via lspci) a "Broadcomm Corporation BCM43225 802.11b/g/n (rev 01)"

Just updated to Fedora 17 via the (unsupported) yum method.
Fedora 17 still boots with akmod-wl installed.

Didn't dare testing to disable/uninstall it yet though.

I tried the (unsupported) yum method last week, and got stuck from 'fixfiles onboot' for the selinux....  I 'tweaked' the instuctions though because I didn't realise my issue was with 'broadcom', and not my 'radeon' card - so it is probably my own fault....  I don't think I installed the f17 akmod-wl either....  Good to know you got it to work - so I may try again some time(following the instructions properly)....

Looking into this issue, I first installed FC17 and had no boot problems. So I took the upgrade route next.

1. install FC16
2. install kmod-wl (from RPMFusion)
3. load wl upon boot (add file with wl listed in /etc/modules-load.d)
4. upgrade to FC17 through preupgrade
5. upgrade completed.
6. removed broadcom-wl-blacklist.conf from /etc/modprobe.d.
7. rebooted to 3.4.2-4.fc17.i686.

The reboot went fine and got wireless connectivity. Could the problem be related to akmod? Did not try that yet.

(In reply to comment #24)
> Looking into this issue, I first installed FC17 and had no boot problems. So
> I took the upgrade route next.

I tested on Dell Latitude E6410 with BCM43224 chip.

I don't think that the installed FC16 (with kmod-wl) affects the boot from the FC17 live usb.
(I even tried booting win7 before FC17 to set the wireless card to a clean state.)

(In reply to comment #25)
> (In reply to comment #24)
> > Looking into this issue, I first installed FC17 and had no boot problems. So
> > I took the upgrade route next.
> 

No, this problem is with systems that won't boot F17, or do a preupgrade from F16 to F17....  Is the BCM43224 in the same series an the BCM4313?  This might help narrow down the problem....

the problem is not 'with' akmod - the problem is 'without' akmod the kernel will not boot....  That is why a fresh F17 system(or preupgraded) will not work....

Same problem as Bapf but on a travelmate 8172t

Booting on fedora-17-kde-live usb key
-> Sytem hang after loading network
-> No escape -> force reboot.

Upgrading from fedora 16 using preupgrade
-> preupgrade d/l and install upgrade properly
-> reboot and select upgrade in grub
-> System hang after loading network
-> No escape -> force reboot.

I installed fedora 17 on the hard drive using an other computer and put it back
- Regular boot
-> System hang at loading plymooth

- Rescue mode
-> works

Acer Travelmate TM8172T here

The Fedora64 KDE Live Spin did boot with those kernel parameters:
  acpi=off b43.blacklist=yes

(rescue mode prevents an easy installation experience)

Hope this helps some people which subscribed here

I have a Dell Lattitude E6410. 8Gb RAM

I've just upgraded from FEDORA 15 to Fedora 17.

I used preupgrade. The upgrade worked OK. Booting the machine after the upgrade was not successful.

I then tried a fresh install DVD and I could boot the machine after the install completed.. 
After a "yum upgrade" I could not boot the machime with the updated kernel

The two kernels are different:
3.3.4-5.fc17.x86_64  (Installed after the fresh install)
3.4.4-5.fc17.x86_64  (Installed after yum update)

So my question is: if one allows the machine to boot and the other does not.... Whats the difference between the two?

I have tried instrustions from comment 29 and no change.

With the problem I have (with my Dell Lattitude E6410), I did notice something strange about the video display. 

I can reproduce the same results consistantly with these four scenarios:

1. With just the the laptop LCD screen the laptop appears not to boot. Black screen. Occational HD LCD flicker.

2. If I plug an external VGA monitor into the laptop at boot, same as above.

3. If I plug an external monitor into the laptop at the Grub2 screen, the machine boots and I get a login screen.

4. If I put the machine on a docking station with two screens attached to it (1 HDMI and 1 VGA), then the machine boots without any problem what so ever. I see a log in screen.

Is the problem with the laptop is defaulting its video output to the external display? If this is the case this might gived the illusion the machine is hanging if no external display is present?

@James:
I think you have some other problem because in my case I get the display output just fine. But the system hangs once it's starting the Network Manager.

I just tried booting Fedora-18-Alpha-TC5-x86_64-Live-XFCE.iso....  Same problem now with fedora 18 as with fedora 17(as expected)....  If I physically unplug my bcm4313 wireless card they all boot just fine(just incase anyone was still in doubt this bug exists)....  Then you can install 'akmod' - plug the bcm4313 back in - and you are good to go....

I am also having the problem with fed 17.
Installed on esx server.everything went ok upto upgrade from fed 16 to fed 17.But after reboot nothing is visible.It went blank with the cursor.
Though its accessible by ssh but GUI is the actual requirement of ours.When i run startx from command line,it just shows wallpaper of the fed 17,,,,,fireworks in the sky,but no menu and no buttons on the screen.

I think that I have a related problem.  Upgraded from 16 to 17 ages ago, no problems.  When the 3.6 kernel first came out (via yum update) the kernel panic-ed on boot.  Dropped back to 3.5.? via grub menu, still got panic on boot.  Dropped back to 3.5.?-1 via grub menu everything worked properly.  Figured I'd wait for a new kmod-wl release to see if that fixed anything (the info on the screen after the panic suggests that wl is involved).  A couple of days later a new kmod-wl was released, I installed it via yum after which ALL of the kernels available in grub menu (first 3.6 and last two 3.5) panic on boot.  Got around the problem by entering wl.disable=1 on the boot line and, after successful boot, insmod the appropriate wl module.  This works on all the kernels that I have installed (including 3.6.2-4 which I upgraded to after this fun began).  Seems odd to me that wl causes the kernel to panic during startup but works fine via insmod on a booted system.

HP Pavilion dm1 (E450)
03:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01)

Hello everybody !

I have 2 (yes two) Acer travelmate 8172 (timelineX) and the same related problem when using fedora live 17 and 18
this laptop works fine with FC16 and I had no problem with older distribs FC14 and FC15.

Here the output of "lspci" :

00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 02)
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02)
00:16.0 Communication controller: Intel Corporation 5 Series/3400 Series Chipset HECI Controller (rev 06)
00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 05)
00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 05)
00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 (rev 05)
00:1c.1 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 2 (rev 05)
00:1c.2 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 3 (rev 05)
00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 05)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev a5)
00:1f.0 ISA bridge: Intel Corporation Mobile 5 Series Chipset LPC Interface Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 4 port SATA AHCI Controller (rev 05)
00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller (rev 05)
00:1f.6 Signal processing controller: Intel Corporation 5 Series/3400 Series Chipset Thermal Subsystem (rev 05)
01:00.0 Network controller: Broadcom Corporation BCM43225 802.11b/g/n (rev 01)
03:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM57760 Gigabit Ethernet PCIe (rev 01)
ff:00.0 Host bridge: Intel Corporation Core Processor QuickPath Architecture Generic Non-core Registers (rev 05)
ff:00.1 Host bridge: Intel Corporation Core Processor QuickPath Architecture System Address Decoder (rev 05)
ff:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev 05)
ff:02.1 Host bridge: Intel Corporation Core Processor QPI Physical 0 (rev 05)
ff:02.2 Host bridge: Intel Corporation Core Processor Reserved (rev 05)
ff:02.3 Host bridge: Intel Corporation Core Processor Reserved (rev 05)

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.