[Mageia-dev] Minimum install of cauldron don't start console

[Wolfgang Bornath]

2012/3/6 Colin Guthrie <mageia at colin.guthr.ie>:
> 'Twas brillig, and Wolfgang Bornath at 06/03/12 17:57 did gyre and gimble:
>> 2012/3/6 Colin Guthrie <mageia at colin.guthr.ie>:
>>> 'Twas brillig, and Wolfgang Bornath at 06/03/12 16:56 did gyre and gimble:
>>>> 2012/3/6 Frank Griffin <ftg at 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