When you first boot up, do you get the graphical "spinfinity" boot screen, the text based 3 progress bar boot screen, or the detailed show-every-message boot screen?

I get the spinfinity boot screen and after a while I get impatient and hit Esc. Then I see the detailed boot messages and eventually the screen becomes all black.

I have tried several times and if I let the spifinity boot screen spin a loooooooong time before I hit Esc I see a text about saving firstbootX.log but then the screen do not become black. However, nothing else happens and this is the file I attached with my description.

What bothers me is that there is no xorg.conf. Has that been changed in Fedora 10 or is it part of the problem?

This bug has been triaged

Unfortunately we don't have kernel modesetting support for your video card yet.  Did you add vga=0x318 to your kernel command line to get the spinfinity animation?

If so, does removing it work around the problem?

(In reply to comment #4)
> Unfortunately we don't have kernel modesetting support for your video card yet.
>  Did you add vga=0x318 to your kernel command line to get the spinfinity
> animation?

No, I did nothing to get this spinfinity.

> 
> If so, does removing it work around the problem?

As I said, I got out of the animation by hitting Esc and it did not circumvent the problem.

The current theory is that there may be a bad interaction between fbcon and X.

Is this machine powerpc by any chance? Basically, spinfinity shouldn't be working for you at all, and I don't know why it does.  It seems like the reason it's working may also be the reason X isn't working.

It's not that spinfinity itself is breaking X (which is why pressing escape doesn't work around the issue for you).

can you attach the contents of /proc/cmdline ?

(In reply to comment #6)
> The current theory is that there may be a bad interaction between fbcon and X.
> 
> Is this machine powerpc by any chance? Basically, spinfinity shouldn't be
> working for you at all, and I don't know why it does.  It seems like the reason
> it's working may also be the reason X isn't working.

No, it's an ordinary x86 machine.
> 
> It's not that spinfinity itself is breaking X (which is why pressing escape
> doesn't work around the issue for you).
> 
> can you attach the contents of /proc/cmdline ?

I'll try, but I am now testing rawhide as of 10/20 with same problem.

(In reply to comment #6)
> The current theory is that there may be a bad interaction between fbcon and X.
> 
> Is this machine powerpc by any chance? Basically, spinfinity shouldn't be
> working for you at all, and I don't know why it does.  It seems like the reason
> it's working may also be the reason X isn't working.
> 
> It's not that spinfinity itself is breaking X (which is why pressing escape
> doesn't work around the issue for you).
> 
> can you attach the contents of /proc/cmdline ?

I am not sure I got the right contents. I booted into rescue mode, did chroot /mnt/sysimage and vim /proc/cmdline and saw:

initrd=initrd.img rescue BOOT_IMAGE=vmlinuz

But this looks like /proc/cmdline from the rescue system. How can I get it from the newly build system when I can't boot it?

When you first turn on the machine, hold down the ctrl key

This will make sure the grub boot menu shows up.

Press "e" to edit the default entry, and then add a "3" on the kernel line and type b to boot

This will boot you into runlevel 3.  You may also want to remove rhgb from that same line.

(In reply to comment #9)
> When you first turn on the machine, hold down the ctrl key
> 
> This will make sure the grub boot menu shows up.
> 
> Press "e" to edit the default entry, and then add a "3" on the kernel line and
> type b to boot
> 
> This will boot you into runlevel 3.  You may also want to remove rhgb from that
> same line.

OK, thanks a lot. /proc/cmdline contains:

ro toot=UUID=a2b90ea1-87f3-4642-954a-e6d19090d844 rhgb quiet 3

And when I launch startx the screen goes all black.

Adam, is this the firstboot bug you fixed today?

(In reply to comment #11)
> Adam, is this the firstboot bug you fixed today?

Probably not?  If he's seeing it when firstboot doesn't run, then no.

Tested the 10/24 rawhide and it boots fine into runlevel 3. However there is no /etc/X11/xorg.conf and also I noticed that anaconda did not probe for the graphics card. So for some reason X is crippled. Needless to say that startx does not work.

I tried adding vga=0x318 to the kernel command line and got a logon display. However, the userID (root) and password were not authenticated, so I was unable to  get further in the logon procedure.

Does my problem stem from rawhide missing support for Matrox mga G550 APG due to the new code named Plymouth? And if so when will it be added to rawhide?

Have build Fedora 10 anew from rawhide of 11/1. Boots correctly on runlevel 3 but produces black screen on runlevel 5. Tried again with vga=0x318 added to the kernel command and rhgb removed and this time it booted correctly on runlevel 5.

Unfortunately,
I have to confirm that this problem still persists in the Release Candidate:
plain install of amd64 involving a G550 succeeds,
but default booting (into graphical mode) stucks into black (Eizo) screens;
even the three-finger-salute did not escape this situation:
a hard reset was needed.

Fortunately,
I can confirm that
- removing "rhgb"
- adding "vga=0x318"
in the kernel boot options - as already proposed above -
still does the trick.

Good luck with the final!
Kind regards
Manfred

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Try booting with "nomodeset" appended to the boot prompt.  Works for me, see bug 474739.

I updated from F8 to F10 two days ago. Same behavior: Xorg retained my xorg.conf with my very special ModeLine, but the ModeLine no longer worked: Black screen (though monitor did not report sync loss). Other modes, such as automatic ones or generic 1024x768@70Hz flickered horribly or made the monitor report sync loss.

Interestingly, on the framebuffer console I could get all the nice modes set with fbset. I extracted their timings (fbset -x) for xorg.conf but Xorg still didn't display any of them properly.

The "nomodeset" kernel boot option did NOT help.
The "vga=0x318" kernel boot option DID help.

Extremely annoying.

Thanks,
Moritz


Graphics card:
  SubVendor: pci 0x102b "Matrox Graphics, Inc."
  SubDevice: pci 0x0f84 "Millennium G550 Dual Head DDR 32Mb"

Monitor:
DDC says
        VendorName   "SNY"
        ModelName    "ea"
It's an Elsa ECOMO 24H96, apparently identical to Sony GDM-FW900.

I have for a long time now used the vga=0x318 boot option to circumvent the bug. I just like to inform that I keep seeing the following messages with dmesg:

matroxfb 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
matroxfb: Matrox G550 detected
matroxfb: probe of 0000:01:00.0 failed with error -1

I believe it is related to this bug.

There are further reports of this in bug #442533 (marked as duplicate); and I hit the "signal out of range" problem immediately on starting the FC11 LiveCD. It was passed on to the hard disk installation.

I did not try setup workarounds yet, just unplugging the monitor during startup.

(In reply to comment #16)

This problem still persists identical the same in Fedora 11 Final.

> > > Assigned To:  	Adam Jackson (ajax)

Adam, R u alive ?

> plain install of amd64 involving a G550 succeeds,
> but default booting (into graphical mode) stucks into black (Eizo) screens;
> even the three-finger-salute did not escape this situation:
> a hard reset was needed.
 
> Fortunately,
> I can confirm that
> - removing "rhgb"
> - adding "vga=0x318"
> in the kernel boot options - as already proposed above -
> still does the trick.

Please cf.
https://bugzilla.redhat.com/show_bug.cgi?id=442533#c27 , c28 , c29 :
   " ... loose ends ... "
   " ... neither Support or QA care much about the issue ... "

Any "vga=..." parameter seems to help with the problem. I did not remove "rhgb".

Anyway, you don't want to have this on a LiveCD for people to test a new release. There are too many competitors around.

(In reply to comment #23)
> Any "vga=..." parameter seems to help with the problem.

Right. That's sufficient (at least with Fedora 11).

> I did not remove "rhgb".

> Anyway, you don't want to have this on a LiveCD for people to test a new
> release. There are too many competitors around.  

Well, as far as the *LiveCD* is concearned, it _might_ be a double windmill, indeed.

Actually, I was talking about my experiences usind the *Installation DVD* directly, which - in contrast to your reported findings - correctly fires up the G550 as well as the EIZO behind. Only _after_ the installation, _after_ the reboot, in contrast to the ease beforehand, the black screen donates it's surprise ... I presume, that might be a strange type of "first-hands-on user-experience" for any (GNU/Linux-) Fedora-novice ...

This bug is still present in Fedora 11; would it be okay to change the version?  Also, I am seeing this bug on two x86 systems with this graphics card, could we change the platform to be a little more inclusive?

Sure, I just did that for you.

Is there any improvement in Fedora 12 Beta (I doubt, but it might be worth trying...)?

Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command

yum upgrade --enablerepo='*-updates-testing'

Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD .

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]

(In reply to comment #27)

> ... without need to install anything on your
> computer ...

Sorry, but that's straight WRONG.

Again:

. . . Booting from CD  &&  Installing succeded -

. . . RE-BOOTING into the INSTALLED system fails       <-----

as e.g. described in detail in Comment #16 .

After this problem (and its reporting in earlier bugs) persists
throughout multiple releases already
(at least back since fedora-9, as far as I remember),
this ill-formed request / advice is ... let's say 'astonishing'.

I don't have my Matrox MGA G550 AGP card any longer. I had to replace it by something else in order to move on, so I don't have the problem anymore.

Others who still have the problem will have to provide any needed info.

I did the upgrade to updates-testing, and I still get a black screen when I boot (if I remove the "vga=0x318" from the boot commands).  Updated xorg-x11 packages were

xorg-x11-drv-evdev-2.2.6-1.fc11.i586.rpm
xorg-x11-drv-intel-2.7.0-8.fc11.i586.rpm
xorg-x11-drv-nouveau-0.0.12-41.20090528git0c17b87.fc11.i586.rpm
xorg-x11-drv-openchrome-0.2.904-1.fc11.1.i586.rpm
xorg-x11-server-common-1.6.4-0.3.fc11.i586.rpm
xorg-x11-server-Xorg-1.6.4-0.3.fc11.i586.rpm

There were no updates for kernel-PAE or xorg-x11-drv-mga.

Well, okay, here are my current kernel and MGA driver packages (F11 + updates-testing):

kernel-PAE-2.6.30.9-96.fc11.i686
xorg-x11-drv-mga-1.4.10-1.fc11.i586


Comparing Xorg.0.log (working) with Xorg.0.log.old (black screen), I see

# diff Xorg.0.log Xorg.0.log.old
7c7
< Kernel command line: ro root=UUID=4f83862d-d977-473f-bbda-793cffae40de vga=0x318
---
> Kernel command line: ro root=UUID=4f83862d-d977-473f-bbda-793cffae40de
15c15
< (==) Log file: "/var/log/Xorg.0.log", Time: Fri Nov  6 15:42:08 2009
---
> (==) Log file: "/var/log/Xorg.0.log", Time: Fri Nov  6 15:39:26 2009
255c255
< (II) MGA(0): VBE DDC Monitor info: 0x8bdba58
---
> (II) MGA(0): VBE DDC Monitor info: 0x9cb8a58
702a703,715
> (II) ImPS/2 Logitech Wheel Mouse: Close
> (II) UnloadModule: "evdev"
> (II) Macintosh mouse button emulation: Close
> (II) UnloadModule: "evdev"
> (II) AT Translated Set 2 keyboard: Close
> (II) UnloadModule: "evdev"
> (II) Power Button: Close
> (II) UnloadModule: "evdev"
> (II) Power Button: Close
> (II) UnloadModule: "evdev"
> (II) MGA(0): [drm] removed 1 reserved context for kernel
> (II) MGA(0): [drm] unmapping 8192 bytes of SAREA 0x27006000 at 0xb7813000
> (II) MGA(0): [drm] Closed DRM master.
#

*** Bug 442533 has been marked as a duplicate of this bug. ***

(In reply to comment #27)

(In confirmation of Fred's comment #30)
  
(In REMINISCENSE of comment #22)
(In REMINISCENSE of comment #16)

> this problem still persists identical the same in Fedora 11 Final

Unfortunately I have to confirm that

  this problem still persists identical the same in Fedora 12 Final

as expected:

> > Plain install of amd64 involving a G550 succeeds,
> > but default booting (into graphical mode) stucks into black (Eizo) screens;
> > even the three-finger-salute did not escape this situation:
> > a hard reset was needed.
 
> > ... adding "vga=0x318"
> > in the kernel boot options ...
> > still does the trick.

Please, be aware that the G550 series is produced furthermore for good reason,
even as a PCIx 1x version !!

It is still en vogue
   - because of it's excellent quality
   - because of no noise (passive heat sink)
   - because it's the last Matrox with really open drivers

for *professional*  (esp. 24/7) applications.       [ Not for gaming, sure ;) ]

YES:
===>  This problem will land at RedHat's feet, at latest with RHEL6.

Unfortunately, nobody seems to really care:
this bug has survived many releases by now - at least since Fedora 8 !!

Please, make this bug a CURRENT ( = Release 12 Final )  one.

Thanks!


Please NOTE:

(In reply to comment #22)

> > > > Assigned To:  	Adam Jackson (ajax)

Is this assignee alive at all?

He has never ever answered in this thread:

> Adam, R u alive ?

Perhaps this bug should be re-assigned to somebody who cares?

(In reply to comment #33)
> Please, be aware that the G550 series is produced furthermore for good reason,
> even as a PCIx 1x version !!

I'm no maintainer, but a bugzapper. But nevertheless...

> It is still en vogue
>    - because of it's excellent quality
>    - because of no noise (passive heat sink)
>    - because it's the last Matrox with really open drivers
> 
> for *professional*  (esp. 24/7) applications.       [ Not for gaming, sure ;) ]

Yeah, then why does this bug exist? Because of Matrox's really open drivers?

> YES:
> ===>  This problem will land at RedHat's feet, at latest with RHEL6.
> 
> Unfortunately, nobody seems to really care:
> this bug has survived many releases by now - at least since Fedora 8 !!

I believe that Matrox should be the one that cares here. Red Hat rarely fixes upstream hardware driver issues, ESPECIALLY on rare hardware such as Matrox graphics.

Please, if you want someone to care, report this either to Matrox or some opensource community gathered around Matrox graphics cards.

> Please, make this bug a CURRENT ( = Release 12 Final )  one.
> 
> Thanks!

Sure, done. But in and of itself, that doesn't increase the chance of it getting fixed.

(In reply to comment #34)

> > ===>  This problem will land at RedHat's feet, at latest with RHEL6.

> I believe that Matrox should be the one that cares here. Red Hat rarely fixes
> upstream hardware driver issues, ESPECIALLY on rare hardware such as Matrox
> graphics.

IFF  _only_ numbers count ...


The FACT that Fedora IS able to boot / install / configure ...
from all of it's Installation Media CLEARLY states
that this is NOT a matter of the driver itself ...
but a matter of configuring the system to boot afterwards...

I myself am exploiting and enjoying a hand-crafted Gentoo for ages,
never ever experiencing any problem with those rock-solid cards ...
Same with other GNU/Linux distro's and *BSD* ...

> Please, if you want someone to care, report this either to Matrox or some
> opensource community gathered around Matrox graphics cards.

It's FEDORA's decision IFF Fedora cares OR IFF RHEL.6 will care ...


> Sure, done.

Thank you very much !


> ... But in and of itself, that doesn't increase the chance of it
> getting fixed.  

Digesting this thread, perhaps you are able to identify
that _I_ am not having _ANY_ problem with this issue at all ...
just voluntarily, I took over the burden to re-report ...
It's up to YOU, which quality of reputation YOU (==Fedora) want to earn ...

IFF it's your goal to silence this issue:
    well, there you go ... I don't mind ...

Kind regards,
Yours respectfully

Manfred


> I'm no maintainer, but a bugzapper.

I will let a maintainer answer this, and explain why this bug isn't fixed the way that you think it could be fixed.

My understanding is pretty limited when it comes to Matrox X/kernel drivers, but I'm certain that if Radeon needed such a workaround, it would be classified as X driver or kernel module bug and forwarded upstream, or fixed by people employed by Red Hat to work on that driver (e.g. Dave Airlie).

I can only imagine how annoying this is, but, AFAIK, Red Hat has no Matrox driver developers, and it has no way to fix issues like this one unless someone from the community provides a patch or a fix gets implemented upstream.

Is there a bugreport on bugs.fd.o?

I have a machine for testing an open source tool that is about to spread widely. It has a Matrox G550 graphics card.

On this machine I have running current/almost current distro versions of Mandriva, OpenSUSE, Debian, Ubuntu, Xandros, Puppy and Fedora.

The only distro having problems with the G550 was Fedora. This does not point to a bug in the driver - or else, all other distros were able to fix it.

Unfortunately, said tool eats up all my personal CPU cycles, so I'm not able to dive deep into the issue. But since Red Hat is still a company selling something and on the other hand profiteering quite a bit from volunteer's work, I figure they could assign someone to that QA problem.

Bottom line is, as stated from others here and elsewhere, that Fedora will get a bad name which might affect Red Hat in turn.

*** Bug 541577 has been marked as a duplicate of this bug. ***

(In reply to comment #20)

This is because using vga=... involves vesafb and prevents                                                                                                                      matroxfb from working.                                                                                                                                                              
With the boot option matroxfb_base.vesa=0x118 there                                                                                                                              should be correct matroxfb logs

(In reply to comment #37)

Can you create this file: /etc/modprobe.d/matroxfb.conf                                                                                                                              
with this line:                                                                                                                                                                      
                                                                                                                                                                                     
options matroxfb_base vesa=0x118                                                                                                                                                     
                                                                                                                                                                                     
to confirm that the default matroxfb: 640x480x8bpp mode is the culprit.                                                                                                              
                                                                                                                                                                                     
Use 0x118 for 1024x768x32bpp or 0x11B for 1280x1024x32bpp                                                                                                                            
For other modes see kernel doc matroxfb.txt

Thanks billiboy, it's good to get some real information about this.

The boot parameter matroxfb_base.vesa=0x11B got an error with my kernel.  The matroxfb.txt file (in the kernel-doc package) suggests using
     video=matroxfb:vesa:0x11B
This doesn't seem to get any errors, but it looks like creating a /etc/modprobe.d/matroxfb.conf as described above (comment #39) does everything I need (except that I use 0x11B).

Regarding RHGB, I now get the character-mode boot animation.  I was getting a graphical animation with vga=0x318, but I prefer what I'm getting now.

dmesg now shows the following matroxfb messages, in case anyone is curious:

matroxfb 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
matroxfb: Matrox G550 detected
matroxfb: MTRR's turned on
matroxfb: 1280x1024x32bpp (virtual: 1280x3276)
matroxfb: framebuffer at 0xDA000000, mapped to 0xf8400000, size 33554432
matroxfb 0000:01:00.0: putting AGP V2 device into 1x mode

(In reply to comment #40)
> The boot parameter matroxfb_base.vesa=0x11B got an error with my kernel. The

If the error message is:
--
Unknown boot option `matroxfb_base.vesa=0x11B': ignoring
--
This is because matroxfb_base is not compiled into the kernel.
This is OK, when the matroxfb_base module is loaded it will pick up the parameter.
You should get the same logs for matroxfb: ... as with the  /etc/modprobe.d/matroxfb.conf later on in dmesg.

> matroxfb.txt file (in the kernel-doc package) suggests using
>      video=matroxfb:vesa:0x11B

My observation was that this parameter is not been picked up while the matroxfb_base module is loaded. You have to use the matroxfb_base.vesa=... parameter and ignore the error message.
Otherwise you get this line in dmesg:
--
matroxfb: 640x480x8bpp (virtual: 640x26214)
--
The reason I described the matroxfb_base.vesa=... parameter is, if you try a live image it is easier to set the boot parameter then inserting the matroxfb.conf.
If I want to install F12 I have to use xdriver=vesa to get the graphical install.
The matroxfb_base module is missing in the install image and no matroxfb_base
parameter has any effect.

> Regarding RHGB, I now get the character-mode boot animation.  I was getting a
> graphical animation with vga=0x318, but I prefer what I'm getting now.

With the vga=... parameter you use the kernel vesafb driver which is capable
to do the graphical animation. The matroxfb kernel driver seems to be not
capable of this.

My conclusion is that the X mga_drv cannot switch the display mode correct.
When kernel matroxfb has set up the correct mode X mga_drv is working as expected.
The kernel matroxfb is starting always in default mode 640x480x8bpp.
You can make your display working if you set the correct initial mode for kernel matroxfb.

Maybe this bug is related: http://bugzilla.kernel.org/show_bug.cgi?id=9709

Yes, I think this is the cause of the problem.  I created a patch as suggested in the kernel.org bug and built myself a new kernel RPM.  After installing the new kernel, removing matroxfb.conf from /etc/modprobe.d and rebooting, my display shows graphics without any problems.

If others experience the same results, this bug should be attributed to the kernel component.

A kernel fix may be in the works:
     http://patchwork.kernel.org/patch/67986/

By the way, if anyone tries to rebuild the kernel RPM, I recommend looking at the instructions in the Fedora Project's Wiki:
     http://fedoraproject.org/wiki/Docs/CustomKernel
and using the following rpmbuild command:
     rpmbuild -bb --with baseonly --with firmware --without debuginfo \
--target=`uname -m` kernel.spec

A test with kde-i386-20091220.17.iso which includes kernel-2.6.32.2-14.fc13.i686.rpm
because of Linux 2.6.32.2 has this in the changelog:
--
Alan Cox (1):
      matroxfb: fix problems with display stability
--
delivers this:

With panel at DVI-connector display ends up with black screen.

With panel at VGA-connector display ends up working as expected.
Virtual terminals are unusable because of default mode 640x480x8bpp.
Modeswitching with KRandRTray is possible.

A test with Fedora-12-i686-Live-KDE.iso delivers this:

With Panel at DVI-Connector display ends up with black screen

With Panel at VGA-Connector display ends up with black screen

With matroxfb_base.vesa=0x11B the panel at DVI-connector is working in the
mode set with the kernel boot parameter.
Virtual terminals are usable.
Modeswitching with KRandRTray ends up with black screen.

My conclusion is there are two bugs. The kernel bug is regarding the initial
mode for the VGA-Connector. The second bug is that the X mga_drv does not
know the correct magic to switch the display mode for the DVI-Connector.
Only the mode set up by matroxfb is working.

The kernel bug is patched in the 2.6.31.9-174 kernel for Fedora 12 (included in a large patch for 2.6.31.9-172 in the changelog).  I can currently only test with a VGA cable and I can confirm Need's findings in comment #44.  The graphical display is working.  The virtual terminal appeared to work - I got a login screen - but I couldn't do anything with it and it had problems displaying after I tried to log in.

Testing on a second system with an identical video card, I get similar results.  With the latest kernel (2.6.31.9-174.fc12) I can boot into graphics mode with no special boot options, but the (VGA) virtual terminals don't work.  Booting into runlevel 3 gives me working virtual terminals.

In case it matters, both of my systems use the PAE i686 kernel.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  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 '12'.

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 12'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 12 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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 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.

A recent fresh install of F14 on my machine no longer shows this problem (as reported in comment #19).

As this was fixed in December 2009 (alas not for my F10 ;-) so I was never able to test the actual fix), I think it's about time to close this bug. Or did someone just set it to "CLOSED WONTFIX"?

I have tried several times and if I let the specificity boot screen spin a long time, here https://www.appletechnicalsupportnumbers.com/how-do-you-contact-apple-customer-service/ I get a clear explanation of the error.

Janny Watson, 

The site below has a solution for the error as well. 

https://www.layoutindex.com/

Janny Watson, 

The site below has a solution for the error as well. 

https://www.layoutindex.com/

There are lots of answer about this bug. If you want to know which celebrity using which hairdryer( https://techgadgetry.in/best-hair-dryer-under-1000-in-india/ ) , makeup kit then check the celebrity news( https://flickprime.com/ ).

Convert your text into stylish font using fancy text generator ( https://textgeneratorfonts.com )