-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It would appear that on May 28, Jonathan Rawle did say: > Christofer C. Bell wrote: > > The graphical boot screen opens a text window and you're presented with > > the actual boot messages if any service fails to start. Successful boot > > messages > > are hidden and the user sees a pretty startup screen. Failed boot > > messages are already displayed as expected so the user can take whatever > > action is necessary to correct the failure. > > > > At least this is the default behavior of my FC1 system. I can't imagine > > that FC2 behaves any differently. > It does still behave in this way, but only for messages after the initial > runlevel is entered, not for rc.sysinit. The rc.sysinit messages still > appear on vt1. This means that if a fsck is in progress, the boot appears > to have frozen - which often people report as a failed boot. And as a home user who left windows behind (in part) because they were always hiding information from me. I'd be VERY frustrated with that long blank wait... And like somebody said, it can be disquieting when you can't see whats happening. I'm real glad to have found out about that from this thread, before my first FC2 fsck (due in about 15-20 boots) caused me to think FC2 had locked up, and start looking to see if the three fingered salute would start a reboot (probably a bad idea if fsck was in the middle of "fixing" anything?) > I wish they'd sort it out so that all the boot messages appear in the same > place (I'd be happy for them all to stay on vt1, then instead of the "view > details" button, it can say "Press Ctrl-Alt-F1 for details") In which case I hope they also put the no-clear option in the default inittab: => # Run gettys in standard runlevels => 1:2345:respawn:/sbin/mingetty tty1 --noclear So the last screenful of the details don't get cleared for the console login prompt... > While we're at it, X still starts twice, once for rhgb, then again for the > login screen. This adds 10-15 seconds to my startup time. With firstboot, > however, the rhgb X session remains open and firstboot reuses it. This is > really nice, so why can't a similar thing happen for an everyday boot? Ouch, So even us runlevel 3 users are waiting for an x startup?? I DO use x, (even most of the time.) But I like to have the option of using console tools at will BEFORE I type startx... So having to wait for an initial x startup is annoying... Methinks I'm testing removing the "rhgb quiet" from my grub.conf! - -- | --- --- | Joe (theWordy) Philbrook <o> <o> | J(tWdy)P ^ | <<jtwdyp@xxxxxxxx>> /---\ "bla bla bla..." | \___/ "...and bla..." At least I know my mouth is running, I just can't find the off button! ############################################################## # You can find my public gpg key at http://pgpkeys.mit.edu/ # ############################################################## -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAt0rHRZ/61mwhY94RAqjjAJ0c9D4tcon4OMOiBZPJpmgajyITAQCeJmSo c9q8WLrrvckTYhZuagAFa4g= =zqFs -----END PGP SIGNATURE-----
