@ andrew > You have to understand that we normally don't fix bugs in a version that > was released. Then why do we claim that we "support" any release? I really hope that you were speaking off-the-cuff. Deciding not to fix bugs (even with the exception of security fixes) means that we DON'T support the release, and every release is at the end of life the day it's released. The wiki page on Time Based Releases (https://wiki.ubuntu.com/TimeBasedReleases) describes a policy that is, fortunately, somewhat more flexible: "What kind of changes are appropriate to make in a released version of Ubuntu? "We only update packages for specific types of changes: * Fixes for security vulnerabilities * Other high-impact bug fixes, for example those which cause data loss * Very conservative, unintrusive bug fixes with substantial benefit and very low risk" This bug clearly falls into the second category, and I would argue it falls into the third category as well. I can't think of many more high-impact bugs than a broken console. Despite our best efforts to making it more "user friendly", Ubuntu and every other GNU/Linux system, needs the command line. This is especially true when dealing with problems with graphics cards and monitors, because the command line is all you have if you can't get X to operate correctly. My users run into this relatively frequently. Example: Example 1: Pancho buys a slick new IYCC "Laredo Cuadrado" desktop computer with 19" widescreen, preinstalled with Ubuntu and preconfigured for the graphics card and monitor. He gives it to Dario, his 15 year old son, who sets it up in his room. The family decides they want to play an online game in the living room, so Dario disconnects the monitor and carries it by the integrated front panel handle to the living room and hooks it up to the 30" LCD monitor/television in the living room. When he fires it up, everything boots up, but when X starts, the monitor gives and "Out of Range" error, meaning not even displayconfig-gtk is visible. He wants to use the console to run "dpkg-reconfigure xserver-xorg", but alas, the console doesn't show anything, just a black screen staring at him. Example 2: Laredo Trucking Co. buys three Laredo Cuadrado desktops for their offices, again with the 19" screens. The cleaning guy knocks over the monitor one night, leaving it in a dozen pieces on the floor. After cleaning it up, the boss sends his secretary out to Best Buy to buy a monitor. She picks up another LCD monitor, but they were out of 19" wide screens, so she gets a 17" regular 4x3 LCD monitor. They fire it up, but X won't start. The IT guy wants to configure the xserver, but can't because the console doesn't work. Example 3: Ubuntu ships an updated version of a driver, xserver-xorg, displayconfig-gtk, or any of a number of packages needed to make X work. Unfortunately, the update overwrites a configuration file or has some other bug that prevents X from starting. Again, the console is broken, so there's not much he can do. Example 4: The upgrade script from Gutsy to Hardy breaks the computer (like the script for Kubuntu broke many computers upgrading from Feisty to Gutsy). Getting the computer working again merely requires running "aptitude update" and "aptitude full-upgrade" from the command line, but the console is invisible, so the user has to first fix the console to be able to fix his system. This bug also meets the second criteria, because a conservative, unobtrusive, low-risk fix is available. From what I've seen here, using the vesafb works very well, even with proprietary graphics drivers. But assuming arguendo that they conflict and further assuming that the community decided to let the proprietary tail wag the open-source dog, it would not be too terribly hard to come up with SOME sort of fix that at the very least allowed the user to work on the console. If the powers that be STILL have a problem with a default boot that allows the user to operate a console when X is running, we could at least make some accomodation by creating an option in GRUB that boots up the system into a command line environment (with networking and other background services loaded as usual), but doesn't start X. Then the user could work on the command line to the user's content and if necessary, execute "startx" to load X. (BTW, if you really, really don't think the console is worth keeping, then it would make more sense not to load tty 1 through 6 in the first place. Running six tty sessions uses up memory and state, and loading them slows down booting. If the console has no benefit, then there is no reason to pay for it in system resources.) I'm at a loss to understand why the kernel team is so adamently hostile to getting the console working. -- Loye Young Isaac & Young Computer Company Laredo, Texas (956) 857-1172