If you boot to runlevel 3 or multi-user.target, tty1 is a getty as before.

The reason that the getty on tty1 is not shown when booting to graphical.target (aka runlevel 5) is due to the line "Conflicts: getty@tty1.service" in the prefdm.service file which is pulled in by graphical.target. Otherwise it should be started fine.

So this problem would only occur if there was an actual problem starting X.

I think it would be better to display some kind of emergency plymouth splash or some kind of diagnostic output or something similar here rather than just clear the screen and show a getty.

WDYT?

I think part of the confusion right now, is it currently depends on how
the installation was done.

On my main cauldron installation, (originally Mandriva 2009,1, updated via
urpmi to 2010,2, than to Mageia 1, alpha 2, then kept up-to-date as
a cauldron install via urpmi, I do not get a tty on tty1 if I add
the 3 to the kernel boot options.

Likely I removed the tty1 getty at some point in the past to avoid
a conflict with the dm.

On my beta 1 install of cauldron, I do get the getty on tty 1.

People testing cauldron should periodically do clean re-installs,
to ensure the problems they are seeing are current, not caused
by past temporary workarounds.

CC: (none) => davidwhodgins

(In reply to comment #1)
> If you boot to runlevel 3 or multi-user.target, tty1 is a getty as before.
> 
> The reason that the getty on tty1 is not shown when booting to graphical.target
> (aka runlevel 5) is due to the line "Conflicts: getty@tty1.service" in the
> prefdm.service file which is pulled in by graphical.target. Otherwise it should
> be started fine.
> 
> So this problem would only occur if there was an actual problem starting X.
> 
> I think it would be better to display some kind of emergency plymouth splash or
> some kind of diagnostic output or something similar here rather than just clear
> the screen and show a getty.
> 
> WDYT?


keep in mind that X failing is usually due to drivers, so some stats about that could be displayed, but also some kind of means to actually get that fixed.

for example some kind of curses thing that has a link to XFdrake en a getty. (much like the rescue in fact), where you can start a console (getty)

i suspect exiting the getty could get back to this curses setup and one option should be to retry starting X

CC: (none) => alien

@Dave: To get your tty1 getty back, just do: systemctl enable getty@.service (this will automatically add a getty@tty1.service symlink)

@AL13N: Yup, I was thinking of some kind of simple GUI to allow the options:
 1. Run Configuration Utility
 2. Try Again
 3. View Errors
 4. Switch to Text Mode Logins

Does that make sense? Anything else needed?

Parsing something about the HW and displaying the obvious problems/solutions might be nice (e.g. detect nVidia and ATi based systems and give some advice about free vs. prop drivers etc., but this can likely come later.

(In reply to comment #2)
> I think part of the confusion right now, is it currently depends on how
> the installation was done.
> 

I think you've hit it exactly.  In the ML thread about this, the system I was using was installed several months ago, and didn't respond to CTRL-ALT-Fn at all.  My laptop, which is a more recent (although still about a month old) fresh install does, but I still have log messages on tty1 and X on tty7.

I guess it's time for fresh installs all around.

CC: (none) => ftg

I've added a very crude initial implementation of this in the initscripts package. If X fails to start it will display a simple warning and then prompt you to press any key at which point it switches to multi-user.target (aka runlevel 3).

(In reply to comment #4)
> @Dave: To get your tty1 getty back, just do: systemctl enable getty@.service
> (this will automatically add a getty@tty1.service symlink)

Just confirming that my tty1 getty is working properly now, in
run level 3 after running
systemctl enable getty@.service

Thanks.

(In reply to comment #6)
> I've added a very crude initial implementation of this in the initscripts
> package. If X fails to start it will display a simple warning and then prompt
> you to press any key at which point it switches to multi-user.target (aka
> runlevel 3).

To test this, I changed the Driver in xorg.conf from ati to none.

Trying to boot into run level 5, left my on tty1 with just the startup
log messages.  I was able to use alt+ctrl+f2 to get to a getty login.

Hmmm, right yeah.

If the DM is installed it will be exec'ed and you won't get the helper code.

So this only works when you don't have a DM installed for now.

Hmm, I wonder how to do this nicely. I don't want to leave a shell around on failure or run the fallback code when it's not appropriate (i.e. when the actual DM exits normally). The latter shouldn't be a problem, but not leaving the shell behind will be tricky :s

OK, so I rewrote the script using nice System controls (OnFailure= directive) and it works great when no DM is installed, but again, when a DM starts, it keeps running even when X does not.

So each of them will have to be patched to exit when X exits with a failure code for anything to work.

I'm not sure if this is a good idea or not - certainly it's a lot of work. I'll discuss with systemd and gdm upstream folks to see what they think generally.

So I've just spoken to Ray (upstream gdm).

He pointed me to this:
https://live.gnome.org/GnomeOS/Design/Whiteboards/ProblemReporting

He also (broadly) agreed with me that gdm should exit with a failure code such that it can bubble up to systemd.

We discussed details in a little more depth regarding how to report errors more generally, including on multi-seat systems. This complicates things as there should be a more structured system for reporting errors back up to multiple displays on different seats and on the same seat when user-switching is engaged.

We reckoned that systemd-logind needs to get more involved with user switching (which actually tied in nicely with my previous desire to make a graphical login prompt appear when switching vts when logged into a graphical target).

I'll still have to take this discussion to Lennart, but I think overall it makes sense.

Ray said we should make gdm exit with an error when X does the same early in the 3.5 cycle (i.e. after mga2) and see how we go.

That's kinda a problem for us, so I'll see if I can do some more experiments to see if I can botch it in the short term.

Just for further reports, I've also now spoken to Lennart. He is also in favour of this idea.

Obviously this does require changes in all he DMs to exit appropriately on errors, so it's not as trivial a roll out as I had hoped (I had assumed they already did this).

But certainly this is something that will be broadly supported overall.

Nice to see Mageia making a difference :)

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

@colin: was this fixed? i don't remember seeing this problem?

or was it workarounded for now?

It wasn't fixed as described here, but various different things happen depending on context:

1. If booting to runlevel 3/multi-user.target then a tty will be shown on tty1 anyway.
2. If booting to runlevel 5/graphical.target and the prefdm.service fails to load, then a warning message will be displayed giving the user the option to switch back to runlevel 3/m-u.tgt.

In the case of 2, if e.g. kdm or gdm "swallow" the failure of X starting (e.g. by continually trying to start it over and over or just by stopping trying but not exiting), then the overall service will not fail and thus the message will not be shown.

So likely more work is needed to cover all cases, but it would be the same amount of work regardless of a switch vs. a message, so probably can be closed. I'll let you decide on that one tho' :)

(In reply to comment #15)

> 2. If booting to runlevel 5/graphical.target and the prefdm.service fails to
> load, then a warning message will be displayed giving the user the option to
> switch back to runlevel 3/m-u.tgt.
> 
> In the case of 2, if e.g. kdm or gdm "swallow" the failure of X starting (e.g.
> by continually trying to start it over and over or just by stopping trying but
> not exiting), then the overall service will not fail and thus the message will
> not be shown.
> 
Is it possible to switch to RL3, despite not seeing the message? (Asking because of bug 7521)

CC: (none) => marja11

@colin

since you're assigned to it, and you'll do the work, you can choose if you want this closed or open... :-)

OK, seeing as this is kinda implemented and any further fixes will be in DMs themselves, I'll mark this one as resolved for now.

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED