2012/3/6 Colin Guthrie <mag...@colin.guthr.ie>: > 'Twas brillig, and Wolfgang Bornath at 06/03/12 17:57 did gyre and gimble: >> 2012/3/6 Colin Guthrie <mag...@colin.guthr.ie>: >>> 'Twas brillig, and Wolfgang Bornath at 06/03/12 16:56 did gyre and gimble: >>>> 2012/3/6 Frank Griffin <f...@roadrunner.com>: >>>>> On 03/06/2012 11:22 AM, Wolfgang Bornath wrote: >>>>>> >>>>>> If you want to address the novice user, what do you think makes support >>>>>> in >>>>>> case of a failing x server easier for the helper AND the novice user, a >>>>>> black screen, a screen without a prompt but with a hanging list of >>>>>> messages >>>>>> instead - or a login prompt from where he can be directed to a solution >>>>>> (or >>>>>> given instructions to provide more information)? >>>>> >>>>> >>>>> Probably a better solution, if you know that X is supposed to come up but >>>>> isn't, is to automatically log him in as some new ID whose shell is a >>>>> script >>>>> something like the rescue console script. The first thing it does is su >>>>> him >>>>> to prompt for the root password, and then presents a character-based >>>>> dialog >>>>> explaining his options, offering to run XFdrake, maybe running rpm/urpmi >>>>> to >>>>> see if all needed packages are installed, and giving him to option to exit >>>>> to a real shell if he wants. >>>> >>>> Yes, that would be the next step on the road to user-friendly desaster >>>> management. >>> >>> Well, that's my whole point!!! >>> >>>> As long as we do not have this a login prompt is better than nothing. >>> >>> So I should spend my time doing this, only to undo it later for a >>> different solution? >>> >>> I'm sorry, but I'm not willing to waste time on this until it's decided >>> that this is the all we're going to do and what we'll ship. >>> >>> As far as things stand I see it as tangential to what I'd like to >>> achieve so I'd rather spend what limited time I have working on that >>> than something that could ultimately be thrown away later. >> >> Ah, ok, I understand your point now. >> The big question is: What is the time span we are talking about here? >> A week, month? Would you think you can achieve this better solution >> until Mageia 2 RC? > > Perhaps by beta2, but more likely by RC. I'll certainly make sure that > for beta2 a minimal install will properly present itself with > multi-user.target by default such that a getty will be shown on tty1 (as > already outlined, the getty on tty1 is only suppressed when there is > supposed to be a graphical login - and only a problem when that fails!). > >> If so, I am totally ok with that. If you think it >> will take longer than that, I do not think we can let this issue leave >> hanging in the air when we approach Mageia 2 final, wasted work or >> not. > > Yeah. I would agree there has to be a limit. I'd say RC2 should be that > limit. If I've not found a better way of doing things by then, I'll do > whatever is needed to make a getty appear... > > [Just to explain further, displaying a tty on failure is tricky due to > the complex interplay of different and conflicting configurations. I > *could* just run agetty manually at the end of the /etc/X11/prefdm > script, but then this then this would be considered by systemd as being > part of the prefdm service and thus if you login and restart prefdm > (which might be common) it would first of all kill the getty itself as > part of the "stopping" procedure! Now if it fails the user would be > dumped back at a login prompt again... not really very user friendly! > Hence, to solve this properly it would really be a matter of changing > the current target (aka runlevel) from default.target (which will be an > alias for graphical.target) to multi-user.target, but this may have > other consequences. I think this latter solution (changing target) is > the correct solution, but it really needs to be played out and tested > thoroughly. I'm also not sure what consequences there are (if any) of > running a command to change the target while running a specific service. > I think all will be fine, but all the same I'd need to investigate. And > after all that of course, we're supposed to still support sysvinit too > so we I'll have to at least look into things mostly working there (I > won't aim for sysvinit to be fully quirk free as it is clearly on the > way out and thus (being realistic) won't get as much time dedicated to > it). So it's not just a five or ten minute job!] > > Col
The force be with you, it will ! -- wobo