Bug 115674

IIRC, anaconda sets the runlevel to 5 unless you do a custom or server
install and select text only login.  Only then will it set the
runlevel to 3. 

Firstboot should now run in text mode if the runlevel is 3 (this is
new in FC2).  However, if you did a text mode anaconda install and
XFree86 was installed and the runlevel was set to 5, I'm not sure how
firstboot is supposed to somehow know to avoid starting in graphical mode.

If firstboot defaulted to a save video mode (60Hz 31.5Khz 640x480
only) it wouldnt be so bad (but I guess thats an installer bug). Maybe
text mode installs should write something to /etc/sysconfig/firstboot
indicating a textual first boot or a "show license and ask " box instead ?

Whether a text mode install should by imply a text mode firstboot is
probably Jeremy's decision to make.  Jeremy mentioned on IRC that
perhaps a text mode installation should automatically imply runlevel
3.  This would cause firstboot to come up in text mode without any
changes to the firstboot code.

Graphical firstboot during a text-mode installation is still an issue in FC4. I
am using X (implies runlevel 5) but I have an external X terminal.

The computer itself has no graphical monitor, that's why I have to use text mode
installation, but with firstboot as it currently exists it is IMPOSSIBLE to
finish the installation.

More recent firstboots have a text mode that runs after text installs.  How is
the unsafe video mode problem now that we are using the X autoconfig code?

I'm not familiar enough with the non EDID behaviour in this case.

The safe mode without EDID is 640x480@60HZ. We've always done 800x600 which is
"mostly safe"

By now its probably the case that few of our users have non EDID capable
displays except TFT and few will have 640x480 TFT!

This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.

Still true

Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers

still true

firstboot is now entirely using X's autoconfiguration code to set up the X
session.  In the future we'll probably be using whatever the new gdm does
instead.  So if you're still seeing dangerous video modes in rawhide post-F9,
that's going to be an X problem.

And of course, there's a working text mode interface as well.