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

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/
+