Bug 843826

Created attachment 600771 [details]
photo of stopped boot

That message is harmless.  The failure you're seeing happens after that point.

Can you provide dmesg from booting with drm.debug=7 ?

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.

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

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

Out of curiosity, do you see this "conflicting fb hw.." message in dmesg for 3.4 boots?

Created attachment 602367 [details]
dmesg of 3.4

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

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.

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

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.

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?

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.

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)

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.

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

(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

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)
___________________

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

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

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)

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.

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.

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.

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?!?!?!

can I get a copy of someones /boot/grub2/grub.cfg please and /etc/default/grub

can people check if they have

terminal_output=gfxterm

in their /boot/grub2/grub.cfg and see if commenting it out helps things any?

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.

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>
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?

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

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.....

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".

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.

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

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.)

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.

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.

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

Gah--wrote Clovis, not sure where that came from, I meant Clevo.

I am also facing problem with kernel 3.5.2-3.fc17.i686, that freeze up and not do anything. My laptop not boot

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

    product: Inspiron 1545 ()
    vendor: Dell Inc.

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.

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.

Correction: I do have "terminal_output gfxterm" directive in grub.cfg; however it is not a kernel parameter.

(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.

(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 ...

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.

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.

(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.

(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.

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*'

(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.

(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.

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

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

(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.

(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.

(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.)

(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 ...

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.

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.