Discussion:
how to remove GUI
(too old to reply)
Michael Morgan
2020-09-11 04:40:01 UTC
Permalink
Dear friend,



I recently installed Debian 9.13 on my machine. I was planning to use it for
scientific computation so GUI is not necessary. For some reason, I installed
the desktop environment with LXDE desktop during installation. Later I
decided to remove them. These two commands were executed:



tasksel remove desktop

apt purge $(tasksel --task-packages desktop)



However, after rebooting the system still has GUI. Here is the result of
"tasksel --list-tasks":



u desktop Debian desktop environment

u gnome-desktop GNOME

u xfce-desktop Xfce

u kde-desktop KDE

u cinnamon-desktop Cinnamon

u mate-desktop MATE

u lxde-desktop LXDE

u web-server web server

i print-server print server

i ssh-server SSH server

u laptop laptop



So it seems the desktop package was removed. But why it still has GUI?



It is pretty much an absolute clean installation. The only thing I did
between OS installation and removing GUI is the installation of cuda package
(for GPU driver). "nvidia-smi" gives:



| 0 1730 G /usr/lib/xorg/Xorg
132MiB |

| 0 2285 G kwin_x11
17MiB |

| 0 2292 G /usr/bin/krunner
2MiB |

| 0 2295 G /usr/bin/plasmashell
45MiB |

| 0 3091 G ...4-linux-gnu/libexec/kscreenlocker_greet
28MiB



So plasmashell and x11 are not part of desktop? What is the correct way to
completely remove GUI?



Thank you.



Michael
Andrei POPESCU
2020-09-11 06:40:02 UTC
Permalink
When removing them you might need to add
-o APT::Autoremove::SuggestsImportant=no
and even
-o APT::Autoremove::RecommendsImportant=no
Err, these won't do much on removing the package, they work only in
combination with 'autoremove'.
Note: the second one in combination with 'autoremove' may remove much
more than actually intended.
This is still very much valid.

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Andrei POPESCU
2020-09-11 06:40:02 UTC
Permalink
Post by Michael Morgan
So it seems the desktop package was removed. But why it still has GUI?
As you found out, removing collections of packages is more difficult
than installing them.

Try running this:

apt -o APT::Autoremove::SuggestsImportant=no autoremove --purge


Do check carefully the list of packages to be removed, in case it
removes packages that are still needed.

If this doesn't work you might still have some LXDE related package
installed. You can find them with

apt list --installed '*lxde*'


When removing them you might need to add

-o APT::Autoremove::SuggestsImportant=no

and even

-o APT::Autoremove::RecommendsImportant=no


Note: the second one in combination with 'autoremove' may remove much
more than actually intended.

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Joe
2020-09-11 08:10:02 UTC
Permalink
On Thu, 10 Sep 2020 23:33:21 -0500
Post by Michael Morgan
Dear friend,
I recently installed Debian 9.13 on my machine. I was planning to use
it for scientific computation so GUI is not necessary. For some
reason, I installed the desktop environment with LXDE desktop during
installation. Later I decided to remove them.
As Andrei has said, 'if I was going there then I wouldn't start from
here..'.

It really would be a lot quicker to reinstall than to spend days trying
to identify what you need to remove. When the time comes in the
installer, don't select anything at all, remove all the ticks, and you
will get a fairly minimal console-only installation.

Alternatively, remove the Display Manager (gdm, xdm, etc.) and whatever
GUI you have remaining should never start, you should boot into just a
console. Only if you have a really tiny hard drive will the wasted
space be a problem.
--
Joe
Henning Follmann
2020-09-11 12:00:01 UTC
Permalink
Post by Michael Morgan
Dear friend,
I recently installed Debian 9.13 on my machine. I was planning to use it for
scientific computation so GUI is not necessary. For some reason, I installed
the desktop environment with LXDE desktop during installation. Later I
[...]

Hello,

may I interject here.
First, is there a particular reason why you installed an older version of
debian?

And second, there is no real reason to go through all of this.
You can make the non gui the default.
With systemd:
systemctl set-default multi-user.target

At that point also disable hibernate and suspend:
systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target


And last, debian has pure blends for specific fields:
https://www.debian.org/blends/

May I suggest Debian Science here?


-H
--
Henning Follmann | ***@itcfollmann.com
Kenneth Parker
2020-09-11 13:10:02 UTC
Permalink
Post by Michael Morgan
Post by Michael Morgan
Dear friend,
I recently installed Debian 9.13 on my machine. I was planning to use it
for
Post by Michael Morgan
scientific computation so GUI is not necessary. For some reason, I
installed
Post by Michael Morgan
the desktop environment with LXDE desktop during installation. Later I
[...]
Hello,
may I interject here.
First, is there a particular reason why you installed an older version of
debian?
And second, there is no real reason to go through all of this.
You can make the non gui the default.
systemctl set-default multi-user.target
+1

I am actually curious, what SystemD does, if it expects graphical.target,
yet the tools (x11, desktop, etc) are no longer available?

One note: My preference, is to set multi-user.target on my current
systems, boot them into Text, sign into root in Console 2, and do the
apt-get "ritual". If it includes a new Kernel (or is, in my opinion,
complex), reboot. And then, as the next step, enter the "systemctl start
graphical.target" command to get to the Desktop.

Good luck!

Kenneth Parker
Greg Wooledge
2020-09-11 14:40:02 UTC
Permalink
Post by Kenneth Parker
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. It's also significantly harder to get the system
to stop clearing the screen after booting, after you logout, and so on.
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.

Other than that, it's pretty much the same.
David Wright
2020-09-11 15:40:01 UTC
Permalink
Post by Greg Wooledge
Post by Kenneth Parker
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.)
Post by Greg Wooledge
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/***@.service.d/noclear.conf
# /etc/systemd/system/***@.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/***@tty1.service
# and
# /lib/systemd/system/***@.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.
Post by Greg Wooledge
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.
Post by Greg Wooledge
Other than that, it's pretty much the same.
Out of its original context, that comment looks somewhat ironic.

Cheers,
David.
Greg Wooledge
2020-09-11 15:50:02 UTC
Permalink
Post by David Wright
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?
It's not as serious as what you reported in the 2018 thread. It's just
an occasional glitch, not easily reproducible, with a trivial workaround.

I only mention it because once in a while, someone sees something like
it and freaks out, thinking the computer is locked up or whatever. They
don't realize they can just hit the Enter key and get a fresh login
prompt, and all is fine.
Felix Miata
2020-09-11 19:20:01 UTC
Permalink
Post by Greg Wooledge
Post by David Wright
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?
It's not as serious as what you reported in the 2018 thread. It's just
an occasional glitch, not easily reproducible, with a trivial workaround.
I only mention it because once in a while, someone sees something like
it and freaks out, thinking the computer is locked up or whatever. They
don't realize they can just hit the Enter key and get a fresh login
prompt, and all is fine.
I have too many installations to keep track of which exhibit this nuisance or not,
but I'm guessing most if not all Buster and Bullseye do it, and maybe even Stretch
& Jessie, which I'm rarely booting any more.
--
Evolution as taught in public schools, like religion,
is based on faith, not on science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata *** http://fm.no-ip.com/
David Wright
2020-09-12 02:10:01 UTC
Permalink
Post by Felix Miata
Post by Greg Wooledge
Post by David Wright
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?
It's not as serious as what you reported in the 2018 thread. It's just
an occasional glitch, not easily reproducible, with a trivial workaround.
I only mention it because once in a while, someone sees something like
it and freaks out, thinking the computer is locked up or whatever. They
don't realize they can just hit the Enter key and get a fresh login
prompt, and all is fine.
I have too many installations to keep track of which exhibit this nuisance or not,
but I'm guessing most if not all Buster and Bullseye do it, and maybe even Stretch
& Jessie, which I'm rarely booting any more.
For me, it started with stretch and continues with buster (not used
bullseye yet). I installed my first stretch on the lenovo with the
more serious problem—reporting that was the only reason I also
mentioned the spurious CR. (I first thought they might be related,
of course.) I hadn't realised anybody else saw them.

Apologies to Greg, I misuderstood the import of your posting,
thinking that the CR had something to do with configuring a
graphical.target without a DM. Duh. I guess you meant that
someone new to a VC login, after always having used a DM login
in the past, might hit this bug and freak out.

Cheers,
David.
David
2020-09-12 11:50:02 UTC
Permalink
Post by Felix Miata
Post by Greg Wooledge
Post by David Wright
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?
It's not as serious as what you reported in the 2018 thread. It's just
an occasional glitch, not easily reproducible, with a trivial workaround.
I only mention it because once in a while, someone sees something like
it and freaks out, thinking the computer is locked up or whatever. They
don't realize they can just hit the Enter key and get a fresh login
prompt, and all is fine.
I have too many installations to keep track of which exhibit this nuisance or not,
but I'm guessing most if not all Buster and Bullseye do it, and maybe even Stretch
& Jessie, which I'm rarely booting any more.
And regarding "just hit the enter key ... and all is fine", this
behaviour does not just occur at a login prompt. If you login quickly
as root to a minimal install as I often do, this behaviour occurs
during root console use, and if one is half-way through typing a
command which suddenly disappears from view, pressing enter could be a
recipe for disaster.

(eg dd before I have added the count= parameter).

So my habit when it occurs has become to: ctrl-u, enter, ctrl-y.

Between that and kernel messages barfing into the terminal text, it's
a pretty shitty user-experience that is embarrassing when observed by
users of any other OS.
David Wright
2020-09-14 02:20:01 UTC
Permalink
Post by David
Post by Felix Miata
Post by Greg Wooledge
I only mention it because once in a while, someone sees something like
it and freaks out, thinking the computer is locked up or whatever. They
don't realize they can just hit the Enter key and get a fresh login
prompt, and all is fine.
I have too many installations to keep track of which exhibit this nuisance or not,
but I'm guessing most if not all Buster and Bullseye do it, and maybe even Stretch
& Jessie, which I'm rarely booting any more.
And regarding "just hit the enter key ... and all is fine", this
behaviour does not just occur at a login prompt. If you login quickly
as root to a minimal install as I often do, this behaviour occurs
during root console use, and if one is half-way through typing a
command which suddenly disappears from view, pressing enter could be a
recipe for disaster.
(eg dd before I have added the count= parameter).
So my habit when it occurs has become to: ctrl-u, enter, ctrl-y.
I use a different technique when I type commands that I consider
"dangerous" (and dd is always that):

I type the command starting with # and, when I've finished,
double-check it. Then I press <Return>, recall it with ↑, and
press <Home>, <Space>, <Delete>, <Return> to execute it, which
also avoids the unprotected line ending up in the history stack.
Post by David
Between that and kernel messages barfing into the terminal text, it's
a pretty shitty user-experience that is embarrassing when observed by
users of any other OS.
(FWIW I've always expected a VC to behave like a console.)

Cheers,
David.
Greg Wooledge
2020-09-14 12:00:01 UTC
Permalink
Post by David Wright
Post by David
And regarding "just hit the enter key ... and all is fine", this
behaviour does not just occur at a login prompt. If you login quickly
as root to a minimal install as I often do, this behaviour occurs
during root console use, and if one is half-way through typing a
command which suddenly disappears from view, pressing enter could be a
recipe for disaster.
(eg dd before I have added the count= parameter).
So my habit when it occurs has become to: ctrl-u, enter, ctrl-y.
I use a different technique when I type commands that I consider
I type the command starting with # and, when I've finished,
double-check it. Then I press <Return>, recall it with ↑, and
press <Home>, <Space>, <Delete>, <Return> to execute it, which
also avoids the unprotected line ending up in the history stack.
It's the same general kind of problem that you can face during terminal
usage in many situations. Something unexpectedly scribbles on your
terminal while you're typing, whether it's modem line noise, or the
kernel warning all users of an imminent reboot, or a background job
you forgot you had running, or whatever.

There are many ways to work around it. My preferred way is to clear
the screen with Ctrl-L (ESC Ctrl-L for me, because I use bash in vi
mode). That will redraw the shell prompt and the partially typed
command after clearing the screen, and allow you to continue typing.
David
2020-09-21 02:20:03 UTC
Permalink
Post by Greg Wooledge
Post by David
And regarding "just hit the enter key ... and all is fine", this
behaviour does not just occur at a login prompt. If you login quickly
as root to a minimal install as I often do, this behaviour occurs
during root console use, and if one is half-way through typing a
command which suddenly disappears from view, pressing enter could be a
recipe for disaster.
(eg dd before I have added the count= parameter).
So my habit when it occurs has become to: ctrl-u, enter, ctrl-y.
It's the same general kind of problem that you can face during terminal
usage in many situations. Something unexpectedly scribbles on your
terminal while you're typing, whether it's modem line noise, or the
kernel warning all users of an imminent reboot, or a background job
you forgot you had running, or whatever.
There are many ways to work around it. My preferred way is to clear
the screen with Ctrl-L (ESC Ctrl-L for me, because I use bash in vi
mode). That will redraw the shell prompt and the partially typed
command after clearing the screen, and allow you to continue typing.
Thank you very much for that advice. I was not aware that bash
"clear-screen" has the feature of repainting the partially typed
command. This exactly addresses what was causing my concern, so I am
less troubled by this now.

For curiosity, I had a look at 'man bash' (on buster), it hints about
this feature in a way that might seem clear to someone who already knew
it, but does not communicate it clearly to me (ie someone with no
prior knowledge of it).

"clear-screen: Clear the screen leaving the current line at the top of
the screen."

The word "leaving" is what misdirects me.

Without knowing the actual behaviour, that sentence suggests to me
that the *current* (ie broken or invisible) line would be *left*
(ie unchanged) at the top. The sentence would better describe to me the
useful behaviour if it read something like:

"clear-screen: Clear the screen, redrawing the current line at the top
of the screen."

or

"clear-screen: Clear the screen, placing the current line at the top
of the screen, and redrawing any readline buffer contents."
David Wright
2020-09-21 14:40:02 UTC
Permalink
Post by David
Post by Greg Wooledge
There are many ways to work around it. My preferred way is to clear
the screen with Ctrl-L (ESC Ctrl-L for me, because I use bash in vi
mode). That will redraw the shell prompt and the partially typed
command after clearing the screen, and allow you to continue typing.
Thank you very much for that advice. I was not aware that bash
"clear-screen" has the feature of repainting the partially typed
command. This exactly addresses what was causing my concern, so I am
less troubled by this now.
BTW, I failed to point out earlier that Ctrl-L is a safer workaround
than Ctrl-U Enter Ctrl-Y for one other reason: Ctrl-L is not adjacent
to the Enter key. You might say "but neither is Ctrl-U", but actually
it is—it's adjacent to Ctrl-J (≡ Enter).

Cheers,
David.

Andrei POPESCU
2020-09-12 09:50:01 UTC
Permalink
Post by David Wright
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.)
As far as I know it depends on the DM, e.g. with lightdm it's root, at
least on buster.

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Greg Wooledge
2020-09-11 12:00:01 UTC
Permalink
Post by Michael Morgan
I recently installed Debian 9.13 on my machine.
So, not the current stable release....
Post by Michael Morgan
What is the correct way to
completely remove GUI?
Well, in this *particular* case, your best course of action would probably
be a clean install of Debian 10. Select only "Standard" (or maybe add
the OpenSSH server) during the initial task selection.

In the more general case, there are two strategies to remove a whole
bunch of packages that have a dependency tree relationship. The first
strategy, which is relatively new, is to count on "apt autoremove",
which is a relatively new feature and has a lot of quirky behavior.
The concept here is that, when you installed the top-level package of
the large dependency tree (whether that's "gnome-core" or "task-something"),
apt will have marked that one package as "manually installed", and
anything else that was brought in at the same time, would not be so
marked. Then, when you want to remove all of them, you first remove
the same top-level package. This doesn't do much on its own, but now
all of the dependent packages have nothing anchoring them. So if you
follow up with an "apt autoremove", it should, in theory, remove all
of the dependent packages.

In my experience, that doesn't work very well, so I've disabled autoremove
on my system.

The other strategy, which is a much older one, relies on you performing
a light analysis of the dependency tree and finding some lynchpin
package that is holding the whole thing up. E.g. with GNOME 2.x, there
was some package like "libgnome-common" or something. If you removed
that, it would remove everything else, because everything in GNOME
depended (directly or indirectly) on this one package.

In the case of a desktop environment, you really have two different
dependency trees to worry about. There's the X server (xorg), and
there's the desktop environment (task-gnome-or-whatever). You can
perform a separate analysis on each of these trees, identify which
low-level libraries or "common" packages are necessary to hold them
up, and remove those.

Or, as we've said a few times now, you can just leave the packages in
place and ignore them. Or do a clean install.
r***@gmail.com
2020-09-11 12:40:02 UTC
Permalink
Thanks for the explanation of the autoremove intent (I had never seen that
explanation before (never looked for it, didn't think I needed it (so far),
but the understanding is helpful).

Nothing new below this line.
Post by Greg Wooledge
In the more general case, there are two strategies to remove a whole
bunch of packages that have a dependency tree relationship. The first
strategy, which is relatively new, is to count on "apt autoremove",
which is a relatively new feature and has a lot of quirky behavior.
The concept here is that, when you installed the top-level package of
the large dependency tree (whether that's "gnome-core" or
"task-something"), apt will have marked that one package as "manually
installed", and anything else that was brought in at the same time, would
not be so marked. Then, when you want to remove all of them, you first
remove the same top-level package. This doesn't do much on its own, but
now all of the dependent packages have nothing anchoring them. So if you
follow up with an "apt autoremove", it should, in theory, remove all of
the dependent packages.
In my experience, that doesn't work very well, so I've disabled autoremove
on my system.
Rogério Brito
2020-09-12 21:40:02 UTC
Permalink
Hi there.
Post by Michael Morgan
I recently installed Debian 9.13 on my machine. I was planning to use it for
scientific computation so GUI is not necessary. For some reason, I installed
the desktop environment with LXDE desktop during installation. Later I
tasksel remove desktop
apt purge $(tasksel --task-packages desktop)
(...)

If you don't mind, I see at least two options:

1 - see what packages you would like to have/need and reinstall from
scratch, if you can afford a re-installation.
2 - if you don't want/can't reinstall, then I would install aptitude and
use its interactive interface for selecting the packages that you need.

I like option 2 and whenever I install any Debian system, that's one of
the first packages that I install (and I completely ignore this tasks
thing). I like my installs to be absolutely minimal at first (they will
inevitably grow with time).

That being said, the system where I am typing this right now has its
filesystem timestamp indicating that it was created in 2011...


Regards,

Rogério Brito.
Loading...