Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #226885 > unrolled thread

how to remove GUI

Back to article view | Back to linux.debian.user

Contents

  how to remove GUI "Michael Morgan" <michaelmorgan937@gmail.com> - 2020-09-11 06:40 +0200
    Re: how to remove GUI Andrei POPESCU <andreimpopescu@gmail.com> - 2020-09-11 08:40 +0200
      Re: how to remove GUI Andrei POPESCU <andreimpopescu@gmail.com> - 2020-09-11 08:40 +0200
    Re: how to remove GUI Joe <joe@jretrading.com> - 2020-09-11 10:10 +0200
    Re: how to remove GUI Henning Follmann <hfollmann@itcfollmann.com> - 2020-09-11 14:00 +0200
      Re: how to remove GUI Kenneth Parker <sea7kenp@gmail.com> - 2020-09-11 15:10 +0200
        Re: how to remove GUI Greg Wooledge <wooledg@eeg.ccf.org> - 2020-09-11 16:40 +0200
          Re: how to remove GUI David Wright <deblis@lionunicorn.co.uk> - 2020-09-11 17:40 +0200
            Re: how to remove GUI Greg Wooledge <wooledg@eeg.ccf.org> - 2020-09-11 17:50 +0200
              Re: spurious CR/LF on tty (was: how to remove GUI) Felix Miata <mrmazda@earthlink.net> - 2020-09-11 21:20 +0200
                Re: spurious CR/LF on tty (was: how to remove GUI) David Wright <deblis@lionunicorn.co.uk> - 2020-09-12 04:10 +0200
                Re: spurious CR/LF on tty (was: how to remove GUI) David <bouncingcats@gmail.com> - 2020-09-12 13:50 +0200
                  Re: spurious CR/LF on tty (was: how to remove GUI) David Wright <deblis@lionunicorn.co.uk> - 2020-09-14 04:20 +0200
                    Re: spurious CR/LF on tty (was: how to remove GUI) Greg Wooledge <wooledg@eeg.ccf.org> - 2020-09-14 14:00 +0200
                      Re: spurious CR/LF on tty (was: how to remove GUI) David <bouncingcats@gmail.com> - 2020-09-21 04:20 +0200
                        Re: spurious CR/LF on tty (was: how to remove GUI) David Wright <deblis@lionunicorn.co.uk> - 2020-09-21 16:40 +0200
            Re: how to remove GUI Andrei POPESCU <andreimpopescu@gmail.com> - 2020-09-12 11:50 +0200
    Re: how to remove GUI Greg Wooledge <wooledg@eeg.ccf.org> - 2020-09-11 14:00 +0200
      Re: how to remove GUI rhkramer@gmail.com - 2020-09-11 14:40 +0200

#226885 — how to remove GUI

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [next] | [standalone]

#226887

[Multipart message — attachments visible in raw view] — view raw

On Jo, 10 sep 20, 23:33:21, Michael Morgan wrote:
> 
> 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

[toc] | [prev] | [next] | [standalone]

#226888

[Multipart message — attachments visible in raw view] — view raw

On Vi, 11 sep 20, 09:32:23, Andrei POPESCU wrote:
> 
> 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

[toc] | [prev] | [next] | [standalone]

#226890

On Thu, 10 Sep 2020 23:33:21 -0500
"Michael Morgan" <michaelmorgan937@gmail.com> wrote:

> 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

[toc] | [prev] | [next] | [standalone]

#226894

On Thu, Sep 10, 2020 at 11:33:21PM -0500, Michael Morgan wrote:
> 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:
> 
[...]

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           | hfollmann@itcfollmann.com

[toc] | [prev] | [next] | [standalone]

#226897

[Multipart message — attachments visible in raw view] — view raw

On Fri, Sep 11, 2020, 7:56 AM Henning Follmann <hfollmann@itcfollmann.com>
wrote:

> On Thu, Sep 10, 2020 at 11:33:21PM -0500, Michael Morgan wrote:
> > 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:
> >
> [...]
>
> 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
>

+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

[toc] | [prev] | [next] | [standalone]

#226901

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.  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.

[toc] | [prev] | [next] | [standalone]

#226902

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.

[toc] | [prev] | [next] | [standalone]

#226903

On Fri, Sep 11, 2020 at 10:35:46AM -0500, David Wright wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#226907 — Re: spurious CR/LF on tty (was: how to remove GUI)

Greg Wooledge composed on 2020-09-11 11:42 (UTC-0400):

> On Fri, Sep 11, 2020 at 10:35:46 -0500, David Wright wrote:

>> 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/

[toc] | [prev] | [next] | [standalone]

#226916 — Re: spurious CR/LF on tty (was: how to remove GUI)

On Fri 11 Sep 2020 at 15:18:10 (-0400), Felix Miata wrote:
> Greg Wooledge composed on 2020-09-11 11:42 (UTC-0400):
> > On Fri, Sep 11, 2020 at 10:35:46 -0500, David Wright wrote:
> 
> >> 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.

[toc] | [prev] | [next] | [standalone]

#226929 — Re: spurious CR/LF on tty (was: how to remove GUI)

On Sat, 12 Sep 2020 at 05:18, Felix Miata <mrmazda@earthlink.net> wrote:
> Greg Wooledge composed on 2020-09-11 11:42 (UTC-0400):
> > On Fri, Sep 11, 2020 at 10:35:46 -0500, David Wright wrote:
>
> >> 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.

[toc] | [prev] | [next] | [standalone]

#226973 — Re: spurious CR/LF on tty (was: how to remove GUI)

On Sat 12 Sep 2020 at 21:45:34 (+1000), David wrote:
> On Sat, 12 Sep 2020 at 05:18, Felix Miata <mrmazda@earthlink.net> wrote:
> > Greg Wooledge composed on 2020-09-11 11:42 (UTC-0400):
> > > 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.

> 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.

[toc] | [prev] | [next] | [standalone]

#226977 — Re: spurious CR/LF on tty (was: how to remove GUI)

On Sun, Sep 13, 2020 at 09:14:54PM -0500, David Wright wrote:
> On Sat 12 Sep 2020 at 21:45:34 (+1000), David wrote:
> > 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.

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.

[toc] | [prev] | [next] | [standalone]

#227186 — Re: spurious CR/LF on tty (was: how to remove GUI)

On Mon, 14 Sep 2020 at 21:56, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> On Sun, Sep 13, 2020 at 09:14:54PM -0500, David Wright wrote:
> > On Sat 12 Sep 2020 at 21:45:34 (+1000), David wrote:

> > > 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."

[toc] | [prev] | [next] | [standalone]

#227210 — Re: spurious CR/LF on tty (was: how to remove GUI)

On Mon 21 Sep 2020 at 12:16:53 (+1000), David wrote:
> On Mon, 14 Sep 2020 at 21:56, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> 
> > 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.

[toc] | [prev] | [next] | [standalone]

#226925

[Multipart message — attachments visible in raw view] — view raw

On Vi, 11 sep 20, 10:35:46, David Wright wrote:
> 
> 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

[toc] | [prev] | [next] | [standalone]

#226895

On Thu, Sep 10, 2020 at 11:33:21PM -0500, Michael Morgan wrote:
> I recently installed Debian 9.13 on my machine.

So, not the current stable release....

> 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.

[toc] | [prev] | [next] | [standalone]

#226896

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.

On Friday, September 11, 2020 07:53:26 AM Greg Wooledge wrote:
> 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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web