Description of problem: display randomly switches between ttys Sometimes, display go to console mode and I have to use Ctrl+Alt+F2 to go back to graphic display. Most of the time (but not everytime) I'm using keyboard. I don't see anything useful in the log, excepted in /var/log/messages Jan 17 16:01:02 brahms systemd[1]: getty@tty1.service holdoff time over, scheduling restart. in /var/log/kdm.log Failed to switch from vt01 to vt02: Input/output error Version-Release number of selected component (if applicable): latest update of cauldron How reproducible: random but frequent I'm not he only one to see this bug https://forums.mageia.org/en/viewtopic.php?f=15&t=1775&p=12808#p12808 Steps to Reproduce: 1. log in 2. use the computer
Hmmm, the tty1.service should not be installed. This is likely due to upgrading systemd from a system that did have tty1 service. In the folder: /etc/systemd/system/getty.target.wants do you have a symlink called: getty@tty1.service ? If so just delete this file. It should have been removed by rpm upgrade, but I guess it's not in this case. If it's not there, I'm a little confused as to why you'd get any messages about getty@tty1.service...
Status: NEW => ASSIGNEDCC: (none) => mageia
Yes, there was a link /etc/systemd/system/getty.target.wants/getty@tty1.service on /lib/systemd/system/getty@.service I've removed it. I'll see tomorrow morning if it closes the bug. Thanks
Out of curiosity, are you fully up-to-date? I presume you had a recent (i.e. the last few weeks) version of systemd installed? It's just that this file was removed from that package a while ago and should not have been left over on your system (and I'm pretty certain you did not put it there manually!)... this is the bit that is a little confusing!
It was a freshly installed alpha3 updated this morning with a urpmi --auto-update
Jan 17 08:11:59 brahms perl: [RPM] systemd-units-38-4.mga2.x86_64 installed Jan 17 08:12:02 brahms perl: [RPM] systemd-units-38-3.mga2.x86_64 removed (No other systemd updates in my logs)
*** Bug 4132 has been marked as a duplicate of this bug. ***
CC: (none) => curtis.h.news
*** Bug 4174 has been marked as a duplicate of this bug. ***
CC: (none) => g.sprik
After several hours of use, no switch this morning. I think the bug is solved. May be the systemd rpm could remove /etc/systemd/system/getty.target.wants/getty@tty1.service
(In reply to comment #1) > Hmmm, the tty1.service should not be installed. > If so just delete this file. > > It should have been removed by rpm upgrade, but I guess it's not in this case. > > If it's not there, I'm a little confused as to why you'd get any messages about > getty@tty1.service... Hmmm, I run all my installs with the getty@tty1.service link. That is solution for <a href="show_bug.cgi?id=3649">bug 3649</a> and I have yet to have a terminal switch. Then again that may be because system boots at runlevel 3 as default.
CC: (none) => junk_no_spam
(In reply to comment #8) > After several hours of use, no switch this morning. I think the bug is solved. My experiences are different. On my system, where all updates from cauldron are installed, I still have very frequent switches. Most of them seem to occur at random, but I can reproduce/trigger one of them: - boot - login (KDE) - open MCC - use the # key in the password - display switches to console mode
Have you removed /etc/systemd/system/getty.target.wants/getty@tty1.service ?
(In reply to comment #11) > Have you removed /etc/systemd/system/getty.target.wants/getty@tty1.service ? It was still there. The rpm upgrade didn't remove this file. I've removed this file manually now, and that solved the problem.
(In reply to comment #12) > (In reply to comment #11) > > > Have you removed /etc/systemd/system/getty.target.wants/getty@tty1.service ? > > It was still there. The rpm upgrade didn't remove this file. > I've removed this file manually now, and that solved the problem. Hmmm, I wonder if ConsoleTTYs= settings in /usr/share/config/kdm/kdmrc makes the problem a variable depending on the tty1 link. I notice my first GUI boot configured mine to manage the terminal since I created the link prior to runlevel 5/GUI login. See https://bugs.mageia.org/show_bug.cgi?id=4097#c11 If the Mageia stand is "no tty1 link", then the errata document needs to tell runlevel 3 users how to find a login terminal. See bug 3649.
(In reply to comment #13) > If the Mageia stand is "no tty1 link", then the errata document needs to tell > runlevel 3 users how to find a login terminal. See bug 3649. I'm still discussing various options with people upstream to decide how best to handle this. I'd prefer that users who configure text-based systems get normal tty's on 1-6 but for graphical users 1-6 is reserved for graphical logins (with perhaps 7+8 always reserved for text logins). Anyway, not got full details yet, but I'll keep it in mind.
(In reply to comment #13) [..] > Hmmm, I wonder if ConsoleTTYs= settings in /usr/share/config/kdm/kdmrc > makes the problem a variable depending on the tty1 link. [...] It's not. This option is to tell to kdm which tty can be use for console login *from* kdm (yep there's an option to log too tty from kdm directly but so far it does not seems to work correctly since when existing from tty you're not switched back to a working kdm). Since tty1 is now supposed to be used directly by X, i removed it from the kdmrc configuration.
CC: (none) => balcaen.john
*** Bug 4248 has been marked as a duplicate of this bug. ***
CC: (none) => epistemepromeneur
*** Bug 3649 has been marked as a duplicate of this bug. ***
Ok, I just hit this with a clean install. I got a console on vt1 and X on vt2, so needless to say it was a pain to work with... I removed the /etc/systemd/system/getty.target.wants/getty@tty1.service, rebooted and X is now on vt1. So we need to figure out why this happend and how to prevent it on both clean installs and upgrades...
Severity: major => criticalPriority: Normal => release_blockerCC: (none) => tmb
However it is solved, make sure there are always text logins avaiable!
CC: (none) => fri
Last night I completed a fresh ftp install from a mirror in France (should that be miroire?) On first boot I saw this bug for the first time. I have got rid of it now. Pressing ENTER in the password field (KDM) to log on to the desktop (which surprisingly turned out to be KDE!) jumped me straight to the vt1 screen. ALT-CTL-F7 brought me back to the desktop (so the login worked), but it was KDE1 It took me by surprise as I had not installed KDE. It happened another couple of times until I got my LXDE started and got rid of KDM and the rest of KDE. The problem has not come back since. Richard
CC: (none) => richard.j.walker
CC: junk_no_spam => (none)
Wrong dependancies on kdm and kde installing LXDE have been fixed. Can we close that bug ?
CC: (none) => ennael1
(In reply to comment #21) > Wrong dependancies on kdm and kde installing LXDE have been fixed. Can we close > that bug ? Yes, feel free to reopen if the bug is still here.
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED