On Fri 11 Sep 2020 at 10:35:19 (-0400), Greg Wooledge wrote: > On Fri, Sep 11, 2020 at 09:02:30AM -0400, Kenneth Parker wrote: > > I am actually curious, what SystemD does, if it expects graphical.target, > > yet the tools (x11, desktop, etc) are no longer available? > > It boots just as you would expect. If there is no display manager > installed, then none will be executed. At that point, you can login > on the console, and either work that way, or run "startx" to start > an X session, exactly the way you did before systemd. > > There are a few *minor* differences. The biggest is that the X session > stays running on the same tty where you ran startx, rather than switching > to the first idle VT.
I don't use a DE so I can't check. Who owns the X server nowadays when running a DM? (With no DM running, ownership changed from root to the user some time ago.) > It's also significantly harder to get the system > to stop clearing the screen after booting, after you logout, and so on. For booting, I use the file: $ cat /etc/systemd/system/getty@.service.d/noclear.conf # /etc/systemd/system/getty@.service.d/noclear.conf 2019-07-15 # https://wiki.archlinux.org/index.php/Disable_clearing_of_boot_messages # Parameter is documented in # /etc/systemd/system/getty.target.wants/getty@tty1.service # and # /lib/systemd/system/getty@.service # [Service] # the VT is cleared by TTYVTDisallocate # TTYVTDisallocate=yes # This file contradicts that default value. [Service] TTYVTDisallocate=no # $ For logout, just edit ~/.bash_logout or remove it. > And every once in a while, the cursor moves to the start of the line a > few seconds after the login prompt has been displayed, but hitting Enter > fixes that. That's the first mention of this phenomenon I recall seeing since I posted https://lists.debian.org/debian-user/2018/03/msg01030.html (which dealt mainly with a more serious problem). I never install a DE/DM and all that stuff, but I get the cursor movement nonetheless. Is that what you're saying? As for the more serious problem reported in my post, I think it only occurred when the laptop was running on the battery. At the time, realising it was to do with that was hampered because I didn't know that the PSU's captive cable entry was iffy, and that it could still be on battery power when connected to the PSU. Eventually the PSU gave out, and its replacement made it obvious that nulls were typed only when on battery power. Since that time, buster has been released, which never showed the phenomenon, the replacement PSU has its captive cable lashed to a coat peg because it's coming off, the connection plug is loose, and the laptop power control section has packed up, so it will only run on the mains. It's not long for this world. > Other than that, it's pretty much the same. Out of its original context, that comment looks somewhat ironic. Cheers, David.