| Summary: | After changing DM in MCC they start on tty7, even after reboot - Pre RC DVD 64 | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | claire robinson <eeeemail> |
| Component: | RPM Packages | Assignee: | Mageia Bug Squad <bugsquad> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | balcaen.john, doktor5000, mageia, marja11, nic, thierry.vignaud |
| Version: | Cauldron | Keywords: | NEEDINFO |
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | MGA2TOO | ||
| Source RPM: | CVE: | ||
| Status comment: | |||
|
Description
claire robinson
2012-05-08 15:48:05 CEST
Manuel Hiebel
2012-05-08 16:09:27 CEST
CC:
(none) =>
mageia, thierry.vignaud Does changing it to GDM allow it to go back to vt1 (after reboot at least). I see that there is a vt7 in the X command line for kdm after changing things in drakconf so this is why it's forced to vt7, but after swithcing back to gdm, there is no vt arg in the X command line (for me it restarted on vt7 as it was the first available one. The logic as to which vt it picks is somewhat wrong (it should have thought "hmmm, vt1 is free I'll use that, but it appears to have actually found the highest in-use vt then used the one above that - I had activated a getty on vt3 - hence the vt4 selection - I suspect newer Xservers do things a little differently). Anyway, we need to find which config KDM is using to put that vt7 in the command line.... The ServerVTs value in the kdmrc appears to be -7. I'm not entirely sure how KDM ever started on VT1 now... Anyway changing this to -1 has the desired effect. I have patches for the mageia-kde4-config package and soft svn but need to run it past the maintainer. CC:
(none) =>
balcaen.john This assumes you're talking about KDM here btw... Other DMs may also be affected. Sorry Colin, it's been a bit hectic. I'll retest to answer your comment 2. After the installation (I think it was installation) it starts with KDM. Using MCC to change to {Insert DM here} it switched to tty7 and remains there no matter what you do. I tried changing to other DM's and rebooting but they always started on tty7 from that point onwards. It was a permanent change. I'll confirm GDM but I'm fairly sure I tried that one too. (In reply to comment #2) > The ServerVTs value in the kdmrc appears to be -7. I'm not entirely sure how > KDM ever started on VT1 now... > Anyway changing this to -1 has the desired effect. > > I have patches for the mageia-kde4-config package and soft svn but need to run > it past the maintainer. Which patch for package ? you mean soft svn ? Anyway i agree to switch to -1 instead of -7. But if the tty 1 is not free ( plymouth feature for example) how can i be sure that kdm won't start on tt2 (since the next free tty is going to be used ) does systemd ensure that tty-tty6 are "pre" allocated ? what about sysvinit ? CC:
(none) =>
lmenut Changes are in the mageia-kde4-config package/svn tree. Under systemd, prefdm.service specifically conflicts with getty@tty1.service so we know there will not be a getty on tty1. Getty's on tty2+ are only allocated when the user switches to that tty, so new kdms should appear on tty2+ if doing e.g. fast user switching. As for sysvinit, I'm not completely sure... Thinking logically, X will get tty1 first and getty will fail to start. But getty's will be started statically on ttys2-6 and thus the next available slot for a new kdm would be 7, 8 etc after that first login. Personally, I think it's not a huge issue for 95% of users so I'm not super worried and as it does behave better under the default systemd install, I think that should probably be fine. Happy to take your opinion too tho'. Testing on an system upgraded from mga1 using RC DVD 64 in virtualbox. Rebooted and took a system snapshot. I switched from KDM (tty1) and KDE to GDM and it restarted fine, took me to the GDM login, albeit a gnomeclassic GDM in vbox. The login is on tty2 though. Logged into GnomeClassic desktop running on tty2 and switched to LXDM. I forgot to check which tty LXDM was running on and logged in without thinking, it started KDE. Logged out and found LXDM was running on tty1. Logged in to LXDE on tty1 and switched to XDM. It restarted the DM service and left me with on tty with just start-up messages (Started LSB: HAL Daemon - which I thought was deprecated but that's another issue.). Checked all the tty's and didn't find a DM at all this time. I could have previously tried the tty an thus occupied it maybe so XDM didn't have anywhere to start. All I can see on tty12 syslog that looks relevant is.. drakedm[6499]: Switching to "XDM" display manager drakedm[6499]: running /etc/rc.d/init.d/dm restart lxdm-binary: pam_tcb(lxdm:session): Session closed for claire systemd-logind[1031]: Removed session 4. polkitd(authority=local): Unregistered Authentication Agent for unix-session:/org/freedesktop/ConsoleKit/Session6 (system bus name :1.157, object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_GB.UTF-8) (disconnected from bus) systemd-logind[1031]: Removed session c2. systemd-logind[1031]: Removed session 5 There are text logins on tty2 to tty6 and a blank screen with flashing cursor on tty7 to tty11. Sorry if my terminology is not correct :) After logging in on tty2 and rebooting XDM has started on tty7. I will make a fresh installation and test again as this is an upgrade. Testing on a fresh installation RC release DVD 64 in virtualbox KDM initially start on tty1. Logged in to KDE (if it makes any difference), changed it to GDM and it restarted the DM service. It had switched to tty2 (tty1 now just a blank screen) with a mageia background but with no GDM login, just a spinning cursor. Ctl-alt-bksp restarted it but it failed again in the same way. Logged in on text tty3 and rebooted. Gnome doesn't much like virtualbox so it may just be down to that. After reboot GDM started, again on tty2. Logged into gnomeclassic on tty2 and, once I'd found MCC, switched to LXDM. It restarted the DM on tty1. Logged in to LXDE on tty1 and changed to XDM. After the DM restart it had changed to tty7. It didn't leave me with a blank window though, it properly showed the XDM. Logged in with XDM and it started KDE on tty7 and rebooted. After reboot XDM was still on tty7. Switched it back to GDM and had the same problem with just a spinning cursor, but it had changed back to tty2. After reboot it was back on tty1. It seems to be all over the place :\ OK, so the problem is all the different DMs have different configs. So I cannot (yet) explain why gdm is starting on vt2 in virtualbox (I can reproduce). Nor why kdm actually *does* start on vt1 when it's config clearly states it should not! lxdm is specifically configured to use the active vt (i.e. vt1) so that's fine, but XDM's config (/etc/X11/xdm/Xservers) specifically said to use the vt7+). I've now fixed that in xdm. I've also pushed a fix for kdm that should make it more deterministic too. So all that remains now is to work out why gdm and xdm cannot use vt1... It's likely because something is outputting to it, but not sure what just yet. Still valid for final prerelease mga2 iso's KDE starts on tty7 after a clean install. 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 kde is now on vt1 but I think gdm did still use an odd one, I'll need to retest. I'd do so in a VM though. Switching back to kdm it is using vt1 again so that much is fixed at least. Keywords:
NEEDINFO =>
(none) Just for general reference, the issues with somewhat random VT usage is due to be fixed soon. It requires a few projects to be updated so it's unlikely something that will be fixed in MGA2, but longer term, issues should be a lot better in Cauldron. Also for the sake of reference: https://fedoraproject.org/wiki/Features/DisplayManagerRework This will likely be landing in upstream GDM and hopefully the other DMs too so I'll probably be following this as it means we can deprecate the prefdm scheme which is just nasty and hacky anyway, and rely on upstream project details.
Florian Hubold
2015-10-04 16:38:18 CEST
CC:
(none) =>
doktor5000
Luc Menut
2016-08-25 16:42:38 CEST
CC:
lmenut =>
(none) Is this issue still valid, and with what DMs? According to the comments it looks like XDM is fixed, I don't know about sddm and gdm still starts on tty7? Keywords:
(none) =>
NEEDINFO (In reply to Nic Baxter from comment #16) > Still valid @ Nic For which DM in which Mageia version was that? (So that we can check cauldron isos with that DM)(In reply to Samuel Verschelde from comment #17) > Is this issue still valid, and with what DMs? According to the comments it > looks like XDM is fixed, I don't know about sddm and gdm still starts on > tty7? I have never seen sddm start on tty7, and current gdm doesn't do that here, either. A DM starting on tty2, if anyone sees that again, belongs in a separate bug report. CC:
(none) =>
marja11 @ Nic Sorry for my impatience, but I'm so sure this bug got fixed that I'll close it. Feel free to reopen, when you still see a DM starting on tty7, though! Status:
NEW =>
RESOLVED |