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

Tue Mar 6 19:45:40 CET 2012

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
+