On Mon, Nov 10, 2008 at 1:49 PM, Bill Nottingham <notting@xxxxxxxxxx> wrote: > Dan Nicholson (dbn.lists@xxxxxxxxx) said: >> It is certainly getting complex, but the current setup is not robust. >> Even if you take away the "I always want getty on tty1" pref, how do >> you handle the case when the display manager is not gdm? Just have >> nothing running on tty1? Because, init currently will not start a >> getty on tty1 in runlevel 5 in any situation. >> >> > There's still the issue of what to do with respect to stopping sometihng >> > on a current tty that GDM is using, if there is something there. >> >> You mean the `telinit 3' from runlevel 5 case? I'm not following exactly. > > Further testing with this is giving me some bizarre errors and hangs > relating to VT switching that don't happen with this patchset backed > out. Unless I can track those down, I can't really recommend using > it. Without doing anything from event.d, there's nothing on tty1 for the `telinit 5' from runlevel 3 case, right? I don't want you to use a broken patch, but I do think the current behavior is wrong. 1. plymouth writes /var/spool/gdm/force-display-on-active-vt even though it has no notion of the initialization environment or display manager.The only advantage of doing this in plymouth is that you can be fairly certain it's only happening at boot. 2. Since there is no way for a getty to start on tty1 in runlevel 5, it will have nothing running on it in either the case of `telinit 5' or a gdm restart. IMO, upstart/event.d is the only place where you can collect enough details to do this correctly, even if you're not considering the "I want X on tty7" pref (personally, I don't care where X starts). So, I'd be willing to help you work on whatever solution you think is appropriate, but I hope you don't just stick with the current situation. An alternative to signaling via initctl would be to add back the "start on started prefdm" to event.d/tty1 and duplicate the runlevel/display logic from event.d/prefdm. Uglier, but it might work more reliably since I didn't really test initctl much. -- Dan -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
