[Mageia-dev] Minimum install of cauldron don't start console
Colin Guthrie
mageia at colin.guthr.ie
Tue Mar 6 19:36:20 CET 2012
'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
--
Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
More information about the Mageia-dev
mailing list