Bug 843826 - fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-27 09:15 EDT by Harald Reindl
Modified: 2013-07-31 22:13 EDT (History)
29 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-31 22:13:11 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
photo of stopped boot (322.16 KB, image/png)
2012-07-27 09:16 EDT, Harald Reindl
no flags Details
dmesg of 3.4 (394 bytes, text/plain)
2012-08-05 12:15 EDT, Harald Reindl
no flags Details
kernel bisect using git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git (2.30 KB, text/plain)
2012-08-20 04:56 EDT, wagner17
no flags Details
ati rv515 fix by reverting pci bus mastering commit (3.04 KB, patch)
2013-05-14 18:57 EDT, Vladimir Brkic
no flags Details | Diff

  None (edit)
Description Harald Reindl 2012-07-27 09:15:58 EDT
kernel-3.5.0-1.fc17 does not boot as long you are not using "nomodeset" as param
see attached photo with message "fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver"

this the last message before boot stops while 9 out of 10 times you do not see this message and the last appearing are detected usb-devices


[root@srv-rhsoft:~]$ lspci
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04)
00:1a.0 USB Controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b4)
00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b4)
00:1c.6 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 7 (rev b4)
00:1c.7 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 8 (rev b4)
00:1d.0 USB Controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a4)
00:1f.0 ISA bridge: Intel Corporation Q67 Express Chipset Family LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller (rev 04)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 04)
01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
02:00.0 USB Controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03)
03:00.0 Network controller: Atheros Communications Inc. AR5008 Wireless Network Adapter (rev 01)


[root@srv-rhsoft:~]$ lsusb
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0e8f:0016 GreenAsia Inc. 4 port USB 1.1 hub UH-174
Bus 001 Device 004: ID 04a9:2213 Canon, Inc. CanoScan LiDE 50/LiDE 35/LiDE 40
Bus 002 Device 003: ID 0bda:0181 Realtek Semiconductor Corp. 
Bus 001 Device 005: ID 046d:0809 Logitech, Inc. Webcam Pro 9000
Bus 001 Device 006: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
Bus 001 Device 007: ID 046d:c045 Logitech, Inc. Optical Mouse
Bus 001 Device 008: ID 0603:00f2 Novatek Microelectronics Corp.
Comment 1 Harald Reindl 2012-07-27 09:16:46 EDT
Created attachment 600771 [details]
photo of stopped boot
Comment 2 Adam Jackson 2012-08-02 12:58:02 EDT
That message is harmless.  The failure you're seeing happens after that point.

Can you provide dmesg from booting with drm.debug=7 ?
Comment 3 wagner17 2012-08-02 21:43:58 EDT
I booted with drm.debug=7 but it's not logging anything.

I tried a bunch of tests and kernel 3.5.0-2.fc17.i686.PAE fails to boot most of the time from a cold boot.  If I unplug my USB keyboard and mouse it boots fine.

Also I get the failure to boot on both of my laptops which have Intel/Radeon integrated/discrete graphics cards.  One laptop has the bios set to boot Intel integrated and the other to discrete Radeon.
Comment 4 Harald Reindl 2012-08-03 04:44:07 EDT
the problem is that the whole system hangs and since it does not boot there is no dmesg and if i boot with "nomodeset" there wil be dmesg but the error is not triggered
Comment 5 Harald Reindl 2012-08-04 07:47:29 EDT
can someone explain me why there was rush needed to push 3.5 to F17 STABLE UPDATES while irgnoring that it does not boot on NON-EXOTIC hardware

i do not believe that the assignment to the graphics-diver is correct and even if: this is a DISTRIBUTION where it is very strange that someone comes to the conclusion "i belivee a other package makes a problem, triggered by my update, but who cares i push mine"

in such cases the way to go would have been 3.4.7 for now as done for F16

thank you very much that there is a security-update out there i can not install on my F17 machines becasue they would be unusable agter install, really; thank you very very much for spit i the face of reporters which are trying packages from koji long before they arrive at updates-testing and sometimes before the maintaienr even knew that the build finished
Comment 6 Josh Boyer 2012-08-05 10:32:53 EDT
Out of curiosity, do you see this "conflicting fb hw.." message in dmesg for 3.4 boots?
Comment 7 Harald Reindl 2012-08-05 12:15:46 EDT
Created attachment 602367 [details]
dmesg of 3.4
Comment 8 Harald Reindl 2012-08-05 12:18:59 EDT
indded the message is contained in 3.4 demsg too, see attachment
not noticed until it was the last one before hang on failed 3.5 boot

i can only guess that it has something to do with graphics because as said it boots with "nomodeset" to KDM login with something around 600x600 resultion

the hang happens exactly at the point where modeset happens normally and instead the big letters at the begin you see your normal resolution for the following boot messages

the last one without "nomodeset" are the fb-conflictiing or some USB-enumerations
Comment 9 Antoine Martin 2012-08-07 04:54:37 EDT
Stops at the same point for me, but "nomodeset" does not help.
I also tried adding: video="1920x1080"
as this was reported somewhere else as a potential workaround, not helping either.

This may be relevant: I use an encrypted /home and this is pretty much the point where I would expect to get prompted for the passphrase.
Comment 10 Harald Reindl 2012-08-07 04:56:48 EDT
in my case no encrypted disks, but all RAID

[root@srv-rhsoft:~]$ df
Dateisystem    Typ      Größe Benutzt Verf. Verw% Eingehängt auf
/dev/md1       ext4       30G    6,9G   23G   24% /
/dev/md0       ext4      497M     61M  437M   13% /boot
/dev/md2       ext4      3,7T    1,6T  2,2T   42% /mnt/dat

[root@srv-rhsoft:~]$ cat /proc/mdstat 
Personalities : [raid10] [raid1] 
md0 : active raid1 sda1[4] sdd1[3] sdc1[0] sdb1[5]
      511988 blocks super 1.0 [4/4] [UUUU]
      
md2 : active raid10 sda3[4] sdd3[3] sdc3[0] sdb3[5]
      3875222528 blocks super 1.1 512K chunks 2 near-copies [4/4] [UUUU]
      bitmap: 6/29 pages [24KB], 65536KB chunk

md1 : active raid10 sda2[4] sdd2[3] sdc2[0] sdb2[5]
      30716928 blocks super 1.1 512K chunks 2 near-copies [4/4] [UUUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk
Comment 11 wagner17 2012-08-11 12:10:27 EDT
I installed kernel-PAE-3.5.1-1.i686 today and the new kernel also failed to boot.  So I installed kernel-PAEdebug-3.5.1-1.i686 and booted it with "debug drm.debug=7 hid.debug=1".  Since no messages are being saved to file I recorded video of the messages and uploaded it to YouTube (see http://youtu.be/J4Gxter_j1s).  The messages don't seem very helpful.  Are there other debug options I should enable?

I have not been able to discern a pattern other than it has a higher frequency of occurring from a cold boot.  Since my earlier comment, I have experienced boot failures with no devices attached to the laptop.
Comment 12 Harald Reindl 2012-08-11 20:48:47 EDT
terrible - the kernel-3.5.0-4.fc17 (lbaeled in the changelog with 3.5.1 RC) even did not come up with my RAID1-boot and RAID10 / by saing the modules are not loaded on thursday,bugzilla did not work half of the day (minutes to get a response) and as i saw on friday the there i decided to remove my phots and stay on 3.4.6 until monday to try it on my office-workstation

since here is reported it will also not work i see no sense in test it 

3.5.x is REALLY the first fedora kernel since years which does not boot at all on my systems - what is going wrong here?
Comment 13 Stuart D Gathman 2012-08-11 21:25:56 EDT
Please note that 3.5.x also does not boot on Radeon systems.  See bug#845388.  I believe that the assignment to the intel driver is incorrect.

Reading through the reports, I note also that some victims have it occasionally work for a warm boot, and that adding debug output sometimes makes it work.  This sounds like a timing problem.
Comment 14 Harald Reindl 2012-08-11 21:29:11 EDT
and that is the reason why i reported the bug orginially to the kernel while the maintainer decided to change it to the intel-driver, changed the subject and shortly after that decided to push 3.5 for updates-stable which is the worst handling of a bug-report i remember while using Fedora on all of my machines since 2006 (FC5/FC6)
Comment 15 Petr Holasek 2012-08-14 05:14:27 EDT
I've first got this freeze with 3.4.6-2.fc17.x86_64, but it appeared non-deterministically. But now, 3.5.1-1.fc17.x86_64 freezes all the time and I am not able to boot machine all the time. I am using nouveau driver with NV96 card.
Comment 16 Harald Reindl 2012-08-14 05:17:49 EDT
very strange

i testetd 3.5.1-1.fc17.x86_64 in a VM with RAID1-boot/RAID10-sysroot
kernel-3.5.0-4.fc17 did not comu up with RAID-devices

after 3.5.1-1.fc17.x86_64 came up with RAID in the VM i decided to give it a try on my Sandy-Brdige Workstation and 3.5.1-1.fc17.x86_64 is working fine

but seeing here users with ATI or Nouveau which freezes let me imagine that there is something unstable with the graphics parts of the kernel, luckily now OK for Intel
Comment 17 Josh Boyer 2012-08-14 08:30:09 EDT
(In reply to comment #16)
> very strange
> 
> i testetd 3.5.1-1.fc17.x86_64 in a VM with RAID1-boot/RAID10-sysroot
> kernel-3.5.0-4.fc17 did not comu up with RAID-devices

3.5.0-4 had a uname vs install path/name issue so dracut would not find any modules that matched.  That is why it was never submitted to updates-testing.

> after 3.5.1-1.fc17.x86_64 came up with RAID in the VM i decided to give it a
> try on my Sandy-Brdige Workstation and 3.5.1-1.fc17.x86_64 is working fine

Repeated attempts at that would be appreciated.  At the moment the theory is there is something racing during initialization.  It may be that 3.5.1 changes things just slightly enough to miss the race.

> but seeing here users with ATI or Nouveau which freezes let me imagine that
> there is something unstable with the graphics parts of the kernel, luckily
> now OK for Intel
Comment 18 Harald Reindl 2012-08-14 08:37:46 EDT
i tested first my workstation at office which was fine
after that i thought it wozld be safe to do the same remote
on my home-machine for which the bugreport initially was made

i have to wait until late at this night for beeing back at home
becuase it did not boot 3.5.1-1.fc17.x86_64
___________________

the only difference between this both machines is the WLAN card for 
hostapd which is not built in the office-workstation and that the Workstation has in the PCIE slot a SATA-card instead the WLAN card, so my guess is that WLAN does trigger a race-condition, but as said: homeserver is down :-(

03:00.0 Network controller: Atheros Communications Inc. AR5008 Wireless Network Adapter (rev 01)
___________________
Comment 19 Harald Reindl 2012-08-14 16:38:20 EDT
i think we should change the subject of this bugreport!

back at home my machine hangs each reboot with kernel-3.5.1-1.fc17.x86_64 somewhere by enumerating USB-devices and i am pretty sure that there is a race-condition shortly before modeset and the "nomodeset" is only a random side-efefct to kump over whatever happens

this would also explain taht people say they have the same problem with ATI and Nvidia cards and why it does not affect all machines - the number and type of USB-devices (Hubs etc.) is the biggest difference and since my office-workstation is 99% ident and even a dd-clone of the machine in front of me it is unlikely that the standard-components are the real problem
Comment 20 Harald Reindl 2012-08-15 15:38:16 EDT
the same with kernel-3.5.2-1.fc17.x86_64
http://koji.fedoraproject.org/koji/buildinfo?buildID=348355

can we PLEASE have a 3.4.8 like build for F16 to fix 
security-bugs on F17 setup until this damend 3.5 works?

why was the rush to 3.5.x done after my bugreport before going to updates-testing?

there is even 3.4.9 available, so 3.4 is NOT EOL: 
http://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.4.9

last recent 3.4 build for F16 but no one for F17
http://koji.fedoraproject.org/koji/buildinfo?buildID=348199
Comment 21 Harald Reindl 2012-08-16 17:49:40 EDT
i try to add all infos i can:

there is a race-condition, office workstation with kernel-3.5.2-1.fc17.x86_64 also stucked at the same point for the frist boot after kernel-update, the second time it came up

i also tested it again on my home-machine while all USB-devices except the built-in card-reader were disconnected with the same result of stop boot before modeset - so i am pretty sure that the "Atheros Communications Inc. AR5008 Wireless" is triggering the race-condition and prvent booting since with this test i excluded additional usb-devices as root-case and this card is the only difference (no way to remove it since i am not good at hardware partly caused due some mdeical operations on both eyes)
Comment 22 wagner17 2012-08-17 07:59:32 EDT
Confirmed same issue with 3.5.2-1.fc17.i686.  I had 7 successful boots and the 8th did not boot.

I have an Intel 5100 wireless card installed on the 2 Lenovo T400 2764 laptops that this issue occurs.
Comment 23 Thomas Mangold 2012-08-18 16:27:48 EDT
Same issue with kernel 3.5.2-1.fc17.x86_64:
- booting stops independently from the kernel parameter nomodeset
- but setting the required resolution manually by adding two lines in grub brings the box up:
  set gfxpayload=1650x1050
  set insmod vbe

With kernel 3.4.x the error message mentioned above arrived too in dmesg, but the booting did not stop.
Comment 24 wagner17 2012-08-18 23:47:55 EDT
I tried 3.6-rc2 from kernel.org and it also failed to boot twice in a row after 3 successful boots.  Here's the proof: http://youtu.be/tJYiBhzUt0Q and http://youtu.be/UlaS3TDFlPs.  I was going to file a kernel.org bug but the first question asks you to identify the subsystem and I don't know.  Maybe I'll have a better idead when I finish the kernel bisect.
Comment 25 Harald Reindl 2012-08-19 06:46:32 EDT
and here some similar bugreports
there are also some for raedon und nvidia

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1016189
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/614085
http://lkml.org/lkml/2012/8/17/495
http://forums.fedoraforum.org/showthread.php?p=1558331

AGAIN: CAN WE HAVE A 3.4.9 BUILD FOR F17 TO FIX SECURITY BUGS ON MACHINES NOT BOOTING WITH 3.5.x?!?!?!
Comment 26 Dave Airlie 2012-08-20 00:16:26 EDT
can I get a copy of someones /boot/grub2/grub.cfg please and /etc/default/grub
Comment 27 Dave Airlie 2012-08-20 02:27:50 EDT
can people check if they have

terminal_output=gfxterm

in their /boot/grub2/grub.cfg and see if commenting it out helps things any?
Comment 28 wagner17 2012-08-20 04:56:29 EDT
Created attachment 605607 [details]
kernel bisect using 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

Yes I have gfxterm in my grub.cfg.  I will test if that makes a difference.
Comment 29 wagner17 2012-08-20 07:03:36 EDT
Commented out terminal_output=gfxterm from /boot/grub2/grub.cfg and was able to complete booting 20 times in a row on two laptops.  One laptop has the BIOS set to Intel and was using kernel-PAE-3.5.2-1.fc17.i686.  The other has the BIOS set to Radeon and was using 3.6-rc2 from kernel.org.  So this seems like a workaround.

Not sure what info you need from a kernel bisect, but when I do "git log" after completing the bisect this is what I get:
"commit 10af77c193681398e5dbe830db181d86047fcd41
Merge: 66f75a5 5f1a389
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Apr 23 09:39:23 2012 -0700

    Merge 3.4-rc4 into tty-next
"

Should I file a bug in kernel.org against 3.6-rc2?
Comment 30 Harald Reindl 2012-08-20 07:45:50 EDT
what does "terminal_output=gfxterm"?

after uncomment on my workstation which boots only randomly with 3.5.x it seems to boot now every time AND i noticed taht outputs in a console (STRG+ALT+F2) are no longer terrible slow, since a longer time a got there rsync-outputs really slow after the command has already finished

i can confirm this on my home-machine in the evening, this one never bootet with 3.5.x and i can not risk do this via SSH again
Comment 31 Harald Reindl 2012-08-20 12:35:07 EDT
confirmed 

after comment out "terminal_output=gfxterm" my homesevrer the first time booted with 3.5.x kernel - where in the miracle of GRUB2-stuff is this to disable if grub2-install will be called in the future?

BTW: grub2 is CRAP, the first time in my life i saw REPEATLY grub freeze the machine while trying to edit the kernel-line.....
Comment 32 Antoine Martin 2012-08-20 15:03:45 EDT
I've also been able to boot 3.5.x by commenting out that line.

/rant: I second the comment on grub2: the grub2 "upgrade" with Fedora 16 (iirc?) left my remote servers unbootable.. That and the gnome3 debacle is really starting to put me off "upgrading".
Comment 33 Stuart D Gathman 2012-08-20 16:52:21 EDT
So disabling gfxterm or using nomodeset gets Fedora server configs booted with 3.5.  But that still leaves workstations with a dead or unusably slow GUI.
Comment 34 Harald Reindl 2012-08-20 16:59:15 EDT
no, igf you read my replies correctly disabling gfxterm works PERFECTLY on workstations, it makes things much faster as they were for many kernel-releases
Comment 35 Stuart D Gathman 2012-08-20 17:16:52 EDT
Sorry, I didn't catch that.  But it *doesn't* work correct on *my* workstation, and that's all that counts!  :-)  (It allows booting to text console, but X server shows black screen.)
Comment 36 Dave Airlie 2012-08-20 19:37:34 EDT
The main problem with gfxterm is was enabled for a time during F17 I think, but since we never regenerated the grub config files, it was stuck turned on for a lot of people, so it made it hard to reproduce for anyone coming from a clean install.

Now the correct fix for F18 is a fix in plymouth to avoid the race condition at startup, and with that even gfxterm should work fine, if a bit ugly.

plymouth 0.8.7 should fix this and is building in koji now. You'd need to regenerate initramfs after it, dracut -f as root.

So Stuart you might have aonther bug since if disabling gfxterm doesn't work alone without nomodeset, so it might be worth filing a new bug so we can track it separately.
Comment 37 Dave Airlie 2012-08-20 19:39:14 EDT
Okay I lied, some people are seeing this on F17, the plymouth fix is for F18,

will have to investigate a bit more then on that side.
Comment 38 Scott Robbins 2012-08-22 22:50:38 EDT
I've been running into the problem  on F17 on laptops with Intel cards, a Clovis and a UX31E.   It will be random--it will keep the machine from booting, but if I boot once or twice more, it will go away. 



Commenting out the line not only seems to have fixed the issue but sped up the boot. Previously, though the error would only happen sometimes, the boot was much slower. 

This is Fedora 17, kernel 3.5.2-3.fc17.x86_64
Comment 39 Scott Robbins 2012-08-22 22:54:23 EDT
Gah--wrote Clovis, not sure where that came from, I meant Clevo.
Comment 40 Noman Khanzada 2012-08-23 04:00:04 EDT

I am also facing problem with kernel 3.5.2-3.fc17.i686, that freeze up and not do anything. My laptop not boot
Comment 41 Noman Khanzada 2012-08-23 06:50:14 EDT
my hardware detail

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 23
model name	: Intel(R) Core(TM)2 Duo CPU     T6400  @ 2.00GHz
stepping	: 10
microcode	: 0xa07
cpu MHz		: 1200.000
cache size	: 2048 KB
Comment 42 Noman Khanzada 2012-08-23 06:55:00 EDT
    product: Inspiron 1545 ()
    vendor: Dell Inc.
Comment 43 wagner17 2012-08-23 23:57:24 EDT
I re-enabled "terminal_output=gfxterm" in my grub2 grub.cfg to test if  https://lkml.org/lkml/2012/8/21/36 fixed the bug, I still got a boot failure on kernel-PAE-3.5.2-3.fc17.i686 and on 3.6-rc3 from kernel.org.
Comment 44 Sam Varshavchik 2012-09-01 09:16:01 EDT
This bug still exists in kernel-3.5.2-3.fc17.x86_64. Prior 3.5.1 and 3.5.2 kernels were never able to boot on this hardware. kernel-3.5.2-3.fc17.x86_64 usually boots for from a hardware reset or a powercycle, but consistently fails to boot after a soft reboot, and gets stuck. At which point initiating a hardware reset usually makes it boot.

I do not have the terminal_output=gfxterm parameter.
Comment 45 Sam Varshavchik 2012-09-01 09:18:33 EDT
Correction: I do have "terminal_output gfxterm" directive in grub.cfg; however it is not a kernel parameter.
Comment 46 Josh Boyer 2012-09-04 09:17:20 EDT
(In reply to comment #45)
> Correction: I do have "terminal_output gfxterm" directive in grub.cfg;
> however it is not a kernel parameter.

Right, we know that.  It's a grub option that seems to trigger a race in the kernel.
Comment 47 Steve Tyler 2012-09-14 01:25:47 EDT
(In reply to comment #31)
...
> after comment out "terminal_output=gfxterm" my homesevrer the first time
> booted with 3.5.x kernel - where in the miracle of GRUB2-stuff is this to
> disable if grub2-install will be called in the future?
...

/etc/default/grub is the grub2 configuration file.[1]

I successfully booted after adding this line to /etc/default/grub:
GRUB_TERMINAL_OUTPUT="console"
and running:
# grub2-mkconfig -o /boot/grub2/grub.cfg

That resulted in this difference, among others:[2]
-terminal_output gfxterm
+terminal_output console

Lightly tested with:
grub2-2.0-0.38.beta6.fc17.x86_64
kernel-3.5.3-1.fc17.x86_64
plymouth-0.8.5-0.2012.04.27.2.fc17.x86_64

$ cat /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Fedora"
GRUB_DEFAULT=saved
#GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm.lv=vg_neptune/lv_walnut_root rd.dm=0  KEYTABLE=us quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0 LANG=en_US.UTF-8"
GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm.lv=vg_neptune/lv_walnut_root rd.dm=0  KEYTABLE=us SYSFONT=latarcyrheb-sun16 rd.luks=0 LANG=en_US.UTF-8"
GRUB_TERMINAL_OUTPUT="console"

[1] GNU GRUB Manual 2.00~rc1
5.1 Simple configuration handling
http://www.gnu.org/software/grub/manual/grub.html#Simple-configuration

[2] There are other differences involving fonts ...
Comment 48 Jaroslav Škarvada 2012-10-26 03:35:44 EDT
I am also affected by this since kernel-3.6.1-1 and it's getting worse and worse (the success rate of reboots lowers dramatically) - it's t500, i915, luks. I have regenerated/reinstalled grub2, but I have there gfxterm, I will retry without it. It seems (in my case) the probability of race increases if the machine is in dock with multi-monitor connected.
Comment 49 aaronsloman 2012-10-29 22:40:46 EDT
I hit this problem (Boot freezes with "conflicting fb hw usage ...") on my Dell Latitude E 6410 with intel graphics and Intel core i5 after I had been running Fedora 17 for some time.

I have recently been running kernels 3.6.3-1_1.cubbi_tuxonice.fc17.i686 and 3.6.3-1.fc17.i686 (trying to sort out problems with resume from hibernate described in bug #862475.

I had often seen "Cannot open font file True" without knowing why. A few hours ago I stumbled across this:
http://forums.fedoraforum.org/showthread.php?t=282574
which recommended editing /etc/default/grub file and add the following to the GRUB_CMDLINE_LINUX line:
   SYSFONT=latarcyrheb-sun16 
and editing  /etc/sysconfig/i18n similarly, then doing:

   grub2-mkconfig -o /boot/grub2/grub.cfg

That last command completely reorganised my grub.cfg file, and after that I could not boot until I found this bug report, then I used a live CD and edited grub.cfg to comment out terminal_output=gfxterm

Since then booting has been fine.

I agree with the comment about grub2 being dreadful. It's extremely difficult to tailor, seems to be very poorly documented, has many bugs -- like this one, seems to have poorly chosen defaults, and does not support editing of the command line properly: many times I've tried to get out of trouble by editing a command line and then find grub2 freezes and I have to reboot.

It seems to have been grub2-mkconfig that screwed me after I had a working grub.cfg file.

One advantage of having "terminal_output=gfxterm" removed is that I now get the grub menu displayed in a readable font at last, as it used to be with the old grub.
What a mess!
Anyhow, many thanks for the comments in this bug report (especially comment #27), without which I would have been completely lost!

Before getting grub.cfg edited,  I did try editing the boot command line to insert nomodeset but that did not help: it still froze.
Comment 50 Jaroslav Škarvada 2012-10-30 05:08:28 EDT
(In reply to comment #49)
I added the following to my /etc/default/grub:
GRUB_TERMINAL="console"

Then regenerated the grub2 config by:
# grub2-mkconfig -o /boot/grub2/grub.cfg

And the problem seems to be workarounded.

The solution with GRUB_TERMINAL="console" in /etc/default/grub did practically the same job as manual remove of terminal_output=gfxterm from /boot/grub2/grub.cfg, but the settings persists further grub2 config regeneration, so such solution is probably more clean.
Comment 51 aaronsloman 2012-10-30 07:06:47 EDT
(In reply to comment #50)
> (In reply to comment #49)
> I added the following to my /etc/default/grub:
> GRUB_TERMINAL="console"
> 
> Then regenerated the grub2 config by:
> # grub2-mkconfig -o /boot/grub2/grub.cfg
> 
> And the problem seems to be workarounded.
> 
> The solution with GRUB_TERMINAL="console" in /etc/default/grub did
> practically the same job as manual remove of terminal_output=gfxterm from
> /boot/grub2/grub.cfg, but the settings persists further grub2 config
> regeneration, so such solution is probably more clean.

Agreed, and I have edited /etc/default/grub -- but I shall never again deliberately run grub2-mkconfig because it reorganises my grub2.cfg in an incomprehensible way, including inserting totally unnecessary sub-menus, and also stopped me getting my desired default menu option (which should have been "0").

Editing /etc/default/grub is a defence against mechanisms that run grub2-mkconfig, which does not seem to happen when Fedora installs a new kernel. I think it runs 'grubby' instead, which does minimal damage to grub.cfg, though it did once copy a wrongly edited root partition from /etc/fstab to grub.cfg, causing serious problems.

See bugs #751875 #756559 if interested.
Comment 52 Steve Tyler 2012-10-30 07:56:28 EDT
OT:

grub2 documentation:
1. http://www.gnu.org/software/grub/manual/grub.html
2. $ info grub2
3. $ rpm -qd grub2-tools

grub2 configuration files:
1. $ cat /etc/default/grub
2. $ sudo ls /etc/grub.d/

grub2 commands:
$ rpm -ql grub2-tools | grep bin

grub2 packages:
$ rpm -qa 'grub2*'
Comment 53 aaronsloman 2012-11-01 22:53:22 EDT
(In reply to comment #52)
> OT:
 ???

Thanks for the links. I don't know what proportion of linux users would be able to make sense of all that information. I found it indigestible, with all sorts of details that don't seem to be relevant to anything I've encountered.

I am not sure it would have helped me discover that I should try commenting out 
"terminal_output=gfxterm"

The grub.cfg file header that says

 # DO NOT EDIT THIS FILE
 #
 # It is automatically generated by grub2-mkconfig using templates
 # from /etc/grub.d and settings from /etc/default/grub

should also point to some much more readable documentation for a relatively naive user who is having trouble and may want tips on what to do.

Better still, there should be a grub interface tool (system-config-grub2 ??)
that does for a grub user what 'wicd-client -n' does for a network user, hiding gory details. 

I know such things take a lot of work, but perhaps as a interim measure the system should be set up to provide by default, a level of functionality in grub.cfg that is guaranteed to work on all systems (or all common platforms) and with a format for grub.cfg that guides a user who is trying to get a machine to boot by editing the file while using a 'live/rescue CD. (I find the Arch CD very good for such rescue situations as it doesn't waste resources on a graphical interface and boots up quickly).

When a kernel update or grub2-mkconfig has screwed up grub.cfg and booting is impossible, the format of grub.cfg should not make manual editing hazardous.

It would also help if the grub boot command editor actually worked reliably, instead of freezing so often. (Compare comment #31)

I remain grateful for all the work done by linux/fedora developers.
Comment 54 Mads Kiilerich 2012-11-02 08:06:40 EDT
(In reply to comment #53)

Summarizing:

There is apparently a bug in the kernel.

It has probably nothing to do with "conflicting fb hw usage" - that is just an informational message that happens to be the last message before s**t happens.

It has nothing to do with grub. It just happens to be possible to work around the problem by telling grub to use different kernel boot parameters.

The bug should not be there in the first place and it should not be necessary to work around it. The situation is not normal and no conclusions should be made from the current state.

Discussion of grub and opinions on grub is completely off topic here and will only make noise that hides the real problem and makes it less likely to get fixed.
Comment 55 Steve Tyler 2012-11-02 11:20:26 EDT
Boot hangs with kernel 3.6.3-1.fc17.x86_64.

OT: There are dozens of grub2 bugs:
Bug 826612 - Problems editing the commands
Bug 830843 - Computer freezes when trying to edit boot entry on grub2 
https://bugzilla.redhat.com/buglist.cgi?component=grub2&product=Fedora
Comment 56 Harald Reindl 2012-11-02 11:51:55 EDT
the porblem is that some idiots throwed away a bootmanager called GRUB and replaced it with a operating-system called GRUB2 with the most foolish way to configure anything i have seen in 20 years working with computers

this whole crap are all sort of shell-scripts as configuration nobody undersatnds really and if you make a wrong touch you can grab your rescue disk
Comment 57 aaronsloman 2012-11-03 20:05:38 EDT
(In reply to comment #54)
> ...
> There is apparently a bug in the kernel.
> 
> It has probably nothing to do with "conflicting fb hw usage" -
> ...
> It has nothing to do with grub. It just happens to be possible to work
> around the problem by telling grub to use different kernel boot parameters.

It's also possible to trigger what appear to be related problems by using grub2-mkconfig

I had been using kernel 3.6.3-1_1.cubbi_tuxonice.fc17.i686 and had previously used 3.6.3-1.fc17.i686. Both worked fine for me, apart from some hibernate/resume problems discussed in another bugreport (Bug #862475 "Why do I need maxcpus=1 to resume from pm-hibernate...")

Then, in order to get rid of mysterious boot warnings "Cannot open font file True" I edited /etc/default/grub followed by: 

     grub2-mkconfig -o /boot/grub2/grub.cfg 

This replaced 'SYSFONT=True' (apparently caused by a bug in anaconda?) with 'SYSFONT=latarcyrheb-sun16' in grub.cfg, and changed the menu structure and various other parameters. 

Immediately after that I could not boot at all, until I used a rescue CD to edit grub.cfg to comment out "terminal_output=gfxterm".

The strange thing is that that line had previously been in grub.cfg when booting worked with the same kernel. So if there was a bug in the 3.6.3-1 kernel it wasn't causing me any trouble till grub2-mkconfig did some damage to grub.cfg. Exactly what I don't know. (There were far too many changes for 'diff' output to be useful.)

Could fixing SYSFONT trigger a kernel bug that is avoided by commenting out the reference to gfxterm ??? Perhaps gfxterm tries to do something that cannot be done with the new font?

I thought I should mention all that in case it provides clues as to what the bug is. (The machine is a Dell Latitude E6410 with intel graphics and intel core i5 cpu - 4core.)

Apologies if this is all irrelevant.
Comment 58 Mads Kiilerich 2012-11-04 09:02:37 EST
(In reply to comment #57)

It would be relevant if you can confirm that downgrading grub2 (and completely reinstalling the boot loader!) could give a working configuration with gfxterm.
Comment 59 aaronsloman 2012-11-04 11:55:57 EST
(In reply to comment #58)
> It would be relevant if you can confirm that downgrading grub2 (and
> completely reinstalling the boot loader!) could give a working configuration
> with gfxterm.

Well this may be such a test. I noticed that kernel 3.6.5-1.fc17.i686 is available in updates-testing, so I used yumex to install it (with kernel-headers). I believe that uses grubby instead of grub2-mkconfig.

That gave me a working 3.6.5-1 that booted OK without gfxterm. So I tried uncommenting the line that excludes it, and it booted fine.

I then tried going back to an older kernel, 3.6.2-4.fc17.i686, which previously failed to boot after I ran grub2-mkconfig. That also booted fine with gfxterm.

(I did not have to go back to the SYSFONT=True situation.)
 
Does that answer the question?

If there's anything different I need to do to test that what grub2-mkconfig does was the source of the boot failure let me know. I would prefer not to have to reinstall Fedora 17

(Having experienced grub.cfg without gfxterm I think I'll comment it out again, as I prefer the larger font for the boot menu! I also suspect the boot menu comes up a bit faster.)
Comment 60 Steve Tyler 2012-11-04 13:00:42 EST
(In reply to comment #59)
> ... I would prefer not to have to reinstall Fedora 17 ...

If you are going to be doing a lot of grub2/kernel testing on bare metal, you might want to allocate a separate hard drive for the purpose ...
Comment 61 Vladimir Brkic 2013-05-14 18:57:07 EDT
Created attachment 747964 [details]
ati rv515 fix by reverting pci bus mastering commit

The patch fixes boot freezing for ATI RV515 in 3.9.2 for me by reverting 2099810f903caa1920f3ef6014fb7f36e4786490 commit and probably breaks something else.
Comment 62 Fedora End Of Life 2013-07-03 19:29:25 EDT
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.
Comment 63 Fedora End Of Life 2013-07-31 22:13:25 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.