On Mon, Nov 29, 2004 at 08:41:22AM +0200, Korpelainen, Seppo wrote: > Update: > >This configuration is working ok for me otherwise, but > >for some unknown reason I can't use mode 5 as the default > >runlevel in the /etc/inittab anymore. The boot process will 'hang' > >in the end of the rc5.d scripts and never opens the gdm screen. > > > >If I set the runlevel at 3, login in text mode and > >use "startx" to start X everything works ok. > I removed the "rhgb" option from the /etc/grub.conf and > now I can use runlevel 5 in inittab. > The same evidence is available here: > http://www.fedoraforum.org/forum/showthread.php?t=27513&page=2 Looks like a number of us are running into the same thing. Mine is on a Dell D600 laptop with a Radeon Mobility 9000 controller. > I lost some eye candy during the boot, but I prefer the text mode > anyways. You may yet have lost more than you thought and you may be left scratching your head figuring out WTF broke if you accidentally stumble into the booby trap that's left (virtual console switching). What I found, diagnosing my problem, is that it appears that switching virtual consoles seem to be broken if you have your current X screen configured in any sort of "multi-head" mode (clone, Xinerama, or simple multiple screens). What this means is that X is fine coming up in a multiheaded mode but, if for any reason, if you or the system switches virtual consoles, you're dead. The "exiting" X server hangs and burns CPU time (you can remotely ssh to the box and do a top and find X hammering the CPU). The reason it fails with rhgb is that most people simply have their xorg.org file default to a multiheaded mode if they've got multiple screens, which means rhgb is in the multihead mode. That then hangs when gdm attempts to switch virtual consoles to bring up the first real X server. So, you evade the problem when you disable rhgb because your main X session becomes the first multihead X session and you're cool because X is never "leaving" one virtual console to switch to another. That's cool as long as you NEVER switch virtual consoles, accidentally or intentionally. The problem can also be evaded by leaving the "Default Layout" alone and creating a new "MultiHead" layout following it. Then, in /etc/X11/gdm/gdm.conf you add "-layout MultiHead" to the server command. That way, rhgb comes up in "normal" (i.e. single head) mode (or something similar) and then gdm switches to your multihead mode of choice. A real problem with BOTH options evading the problem is that virtual consoles switching IS STILL BROKEN. Try hitting "Cntrl-Alt-Fn" and see what happens. It would be my guess that you will be toast (save your work before trying this). Doesn't matter if you are going to a console screen or another GDM/X session. The one you are switching from hangs and starts burning CPU time. You can ssh into the system from another system, kill that X process (-QUIT seems to do it, -HUP and -TERM do not) and then do a "gdm-restart" and the screen will recover, though you've lost your session. I also found that I can have the first GDM session start "standard" (as long as rhgb is booting "standard") and a second one start multihead, and that works too. You just can't switch from the second one to the first one (which makes the first one rather useless). That all DID work under FC2. If you configure a multihead GDM server on anything other than the LAST one, GDM is going to switch to another VC and you will be left dead, staring at the login screen of the first VC with multiple heads. I was afraid it was something peculiar that had happened with the Radeon driver code, but now it sounds like it's much more generic to the multihead logic in the X server. > -- seppo > ----------------------------------------- > ============================================================ The > information contained in this message may be privileged and confidential > and protected from disclosure. If the reader of this message is not the > intended recipient, or an employee or agent responsible for delivering > this message to the intended recipient, you are hereby notified that any > reproduction, dissemination or distribution of this communication is > strictly prohibited. If you have received this communication in error, > please notify us immediately by replying to the message and deleting it > from your computer. Thank you. Tellabs > ============================================================ > > > -- > fedora-list mailing list > fedora-list@xxxxxxxxxx > To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list Mike -- Michael H. Warfield | (770) 985-6132 | mhw@xxxxxxxxxxxx /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
Attachment:
pgpievcTYO1JF.pgp
Description: PGP signature
