Bug#966414: general: After upgrade to testing, VT1 is no longer usuable
Hi Helge, > Thanks for the explanation. It's just a pitty, it worked all the years > (ever since I can remember, actually, basically since the 90s) until I I cannot agree more with you than 100%, but tell this to, well, not surprisingly, GNOME and their rework of everything, and Debian following blindly. > So hopefully it can be restored soon. That would surprise me. Best Norbert -- PREINING Norbert https://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#966414: general: After upgrade to testing, VT1 is no longer usuable
Hello Norbert, On Mon, Feb 01, 2021 at 11:34:11AM +0900, Norbert Preining wrote: > On Sun, 31 Jan 2021, Helge Kreutzmann wrote: > > is there any chance to get my VT 1 back, i.e. this fixed before the > > release of bullseye? > > From the explanations given by Simon I don't see a way how this could > work out. Sddm cannot enable getty on tty1, because this would conflict > with say gdm in case the admin decides to switch to gdm. > > This is probably up to a Debian-wide policy decision on what ttty needs > to be used by DMs, and how other ttys are handled. > > But that will surely not happen til bullseye release. > > But this is just IMHO. Thanks for the explanation. It's just a pitty, it worked all the years (ever since I can remember, actually, basically since the 90s) until I decided to switch to Testing last year. And yes, I used different display manager chooser (kdm, xdm (long, long ago) and the last years sddm). So hopefully it can be restored soon. Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: PGP signature
Bug#966414: general: After upgrade to testing, VT1 is no longer usuable
On Sun, 31 Jan 2021, Helge Kreutzmann wrote: > is there any chance to get my VT 1 back, i.e. this fixed before the > release of bullseye? >From the explanations given by Simon I don't see a way how this could work out. Sddm cannot enable getty on tty1, because this would conflict with say gdm in case the admin decides to switch to gdm. This is probably up to a Debian-wide policy decision on what ttty needs to be used by DMs, and how other ttys are handled. But that will surely not happen til bullseye release. But this is just IMHO. Best Norbert -- PREINING Norbert https://www.preining.info Fujitsu Research Labs + IFMGA Guide + TU Wien + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#966414: general: After upgrade to testing, VT1 is no longer usuable
Hello sddm maintainers, is there any chance to get my VT 1 back, i.e. this fixed before the release of bullseye? If you need any further information I'm available to provide those (and test things if needed). Thanks & Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: PGP signature
Bug#966414: general: After upgrade to testing, VT1 is no longer usuable
Hello Simon, thanks for your ultra-fast reply! On Tue, Jul 28, 2020 at 10:05:34AM +0100, Simon McVittie wrote: > On Tue, 28 Jul 2020 at 10:37:40 +0200, Helge Kreutzmann wrote: > > X is running on VT 7, so this is not the cause (and it does so for > > many years already). > ... > > In http://0pointer.de/blog/projects/serial-console.html I read that X > > should > > start on VT1? Maybe systemd is no confused? > > It depends what starts X on your system. Display managers are encouraged > to behave as described in that article, but not all do. I use sddm. GNOME is not in use at all, my wife uses KDE, and I use WindowMaker. > GNOME's GDM (gdm3 in Debian) is an example of a display manager that > does behave in that way. Recent versions of GDM use tty1 for GDM's own > Wayland or X11 "greeter" (login screen), and ask systemd-logind for one > additional VT per Wayland/X11 login session. By default, systemd-logind > will start allocating VTs from tty2..tty5 if they have not already been > used for a text-mode (getty) login prompt, skip tty6 (which it reserves > for a text-mode login prompt), and continue from tty7. If you switch to > tty2..tty5 before they have been used for a graphical login session, > they will get a text-mode login prompt instead; if you visit all of > tty2..tty5 before the first graphical login, then the first graphical > login will end up on tty7. See logind.conf(5) for more details. Thanks, yes, I looked at logind.conf(5). And tty2 and so on behave as they did in stable, just tty1 no longer does. > Other display managers like lightdm, sddm or xdm might either be using > tty1 (as encouraged by systemd) or tty7 (more traditional on Debian > systems), and they might either reuse the greeter's X11 display for the > user's login session (as xdm traditionally did) or allocate a separate > VT for each login session (like GDM does). > > GDM specifically conflicts with getty@tty1.service, so that it can take > over tty1 when the system boots in graphical mode, while leaving a getty > on tty1 when the system boots in text mode. Other display managers might > do something similar, or not. I found "getty@tty1.service", however, I'm not sure I understood it. There is not dedicated man page for it and systemd-getty-generator(8) talks about serial gettys, not virtual ones. > I don't think anyone is going to be able to solve this bug, or even say > whether it *is* a bug, without more information about your system - in > particular, what display manager you are using. SDDM, because it lets us select the window manager (although it is rather dump, unfortnately). So I get this might be an interaction issue between the updated SDDM and the updated systemd? > > see all boot messages [on tty1], just if I need them > > During a normal boot, by default the screen is cleared before showing > the login prompt, so the boot messages will not be visible anyway. > > However, systemd's rescue.target (the equivalent of sysvinit single user > mode, runlevel 1) and emergency.target (like runlevel 1, but more so) > do not do this. By default, the grub bootloader generates options for > "recovery mode", which is implemented by adding "single" to the kernel > command line to select systemd rescue.target or sysvinit runlevel 1 > as applicable. Well, what I meant was that it would be nice to always have the full (last screen, at least) of boot messages on VT1, but this is a rather very minor issue. Thanks! Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: PGP signature
Bug#966414: general: After upgrade to testing, VT1 is no longer usuable
On Tue, 28 Jul 2020 at 10:37:40 +0200, Helge Kreutzmann wrote: > X is running on VT 7, so this is not the cause (and it does so for > many years already). ... > In http://0pointer.de/blog/projects/serial-console.html I read that X should > start on VT1? Maybe systemd is no confused? It depends what starts X on your system. Display managers are encouraged to behave as described in that article, but not all do. GNOME's GDM (gdm3 in Debian) is an example of a display manager that does behave in that way. Recent versions of GDM use tty1 for GDM's own Wayland or X11 "greeter" (login screen), and ask systemd-logind for one additional VT per Wayland/X11 login session. By default, systemd-logind will start allocating VTs from tty2..tty5 if they have not already been used for a text-mode (getty) login prompt, skip tty6 (which it reserves for a text-mode login prompt), and continue from tty7. If you switch to tty2..tty5 before they have been used for a graphical login session, they will get a text-mode login prompt instead; if you visit all of tty2..tty5 before the first graphical login, then the first graphical login will end up on tty7. See logind.conf(5) for more details. In practice this usually means that GNOME systems have the greeter on tty1, the first graphical login on tty2, and the second and subsequent graphical logins (if you use "fast user switching" to get multiple parallel graphical logins) on tty3..tty5. Other display managers like lightdm, sddm or xdm might either be using tty1 (as encouraged by systemd) or tty7 (more traditional on Debian systems), and they might either reuse the greeter's X11 display for the user's login session (as xdm traditionally did) or allocate a separate VT for each login session (like GDM does). GDM specifically conflicts with getty@tty1.service, so that it can take over tty1 when the system boots in graphical mode, while leaving a getty on tty1 when the system boots in text mode. Other display managers might do something similar, or not. I don't think anyone is going to be able to solve this bug, or even say whether it *is* a bug, without more information about your system - in particular, what display manager you are using. > see all boot messages [on tty1], just if I need them During a normal boot, by default the screen is cleared before showing the login prompt, so the boot messages will not be visible anyway. However, systemd's rescue.target (the equivalent of sysvinit single user mode, runlevel 1) and emergency.target (like runlevel 1, but more so) do not do this. By default, the grub bootloader generates options for "recovery mode", which is implemented by adding "single" to the kernel command line to select systemd rescue.target or sysvinit runlevel 1 as applicable. smcv
Bug#966414: general: After upgrade to testing, VT1 is no longer usuable
Package: general Severity: normal I upgraded from Debian Stable to Testing some days ago (see #964477 for some information why this was not entirely smooth). I did not upgrade the kernel. Now the virtual terminal 1 is no longer usuable. It only prints the very few lines of the boot process and some more lines when shutting down. After boot I see: /dev/mapper/samd--vg-root: clean, 571317/102 files, 3545957/4077568 blocks [3.477202] Error: Driver 'pcspkr' is already registered, aborting... [3.854191] DVB: Unable to find symbol simple_tuner_attach() X is running on VT 7, so this is not the cause (and it does so for many years already). I'm not sure which other programm could "lock" VT1. In http://0pointer.de/blog/projects/serial-console.html I read that X should start on VT1? Maybe systemd is no confused? I see that there is a /etc/systemd/system/getty.target.wants/getty@tty1.service -> /lib/systemd/system/getty@.service file, but this link is from 2016 and the file under /lib does not indicate any special handling of VT1 (however, it might explain why in #964477 the prompts where not localized). It would be great to have VT1 again ususable and to see all boot messages there, just if I need them (there are in the logs, of course as well, so this is not too important but very nice). -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: PGP signature
