Good day everyone,
I'm using trinity 14.0.5 from preliminary stable builds on devuan ascii (debian stretch).
Through the most recent upgrade, that I executed on 2018-07-02 11:42:01, tdm (amongst a couple others) got upgraded:
tdm-trinity:amd64 (4:14.0.5~pre39-0debian9.0.0+6, 4:14.0.5~pre42-0debi an9.0.0+6)
After this upgrade tdm wouldn't start anymore and in /var/log/boot I found this error message:
Not starting Trinity Display Manager (tdm); it is not the default display manager.
The file is there: $ ls -l /etc/X11/default-display-manager -rw-r--r-- 1 root root 14 Jul 2 11:42 /etc/X11/default-display-manager
And it says: $ cat /etc/X11/default-display-manager /usr/bin/slim
Solution:
$ dpkg-reconfigure tdm-trinity
Of course, tdm was the default display manager already before the upgrade, and, as you can guess from the above, slim is installed, too.
I think, it should not be necessary to reconfigure the display manager, or, least, the user should be prompted to do so at installation.
IIRC, this happened already at the previous upgrade to ~pre39.
Has anybody seen this? Do you think it is a bug?
Regards, Stefan
On Tuesday 03 July 2018 15.49:06 Stefan Krusche wrote:
Good day everyone,
(...)
Through the most recent upgrade, that I executed on 2018-07-02 11:42:01, tdm (amongst a couple others) got upgraded:
(...)
After this upgrade tdm wouldn't start anymore and in /var/log/boot I found this error message:
(...)
Solution:
$ dpkg-reconfigure tdm-trinity
(...)
Has anybody seen this? Do you think it is a bug?
Regards, Stefan
Debian Stretch here. Same thing happened with tha last update/upgrade
Obviously Debian/Devuan got updated too and reset the display manager. As far as I am concerned it's not a bug, just an result of the distribution not respecting modifications by the user and going back to some config file it used for it's own setup.
I my case I found myself loging in from Gnome again.
Thierry
On Tue, 3 Jul 2018 16:54:51 +0200 Thierry de Coulon tcoulon@decoulon.ch wrote:
Debian Stretch here. Same thing happened with tha last update/upgrade
Obviously Debian/Devuan got updated too and reset the display manager. As far as I am concerned it's not a bug, just an result of the distribution not respecting modifications by the user and going back to some config file it used for it's own setup.
I my case I found myself loging in from Gnome again.
It is a bug, debconf sysytem should remember default-x-display-manager choice and preserve it on upgrades.
On Tuesday 03 July 2018 07:54:51 Thierry de Coulon wrote:
On Tuesday 03 July 2018 15.49:06 Stefan Krusche wrote:
Good day everyone,
(...)
Through the most recent upgrade, that I executed on 2018-07-02 11:42:01, tdm (amongst a couple others) got upgraded:
(...)
After this upgrade tdm wouldn't start anymore and in /var/log/boot I found this error message:
(...)
Solution:
$ dpkg-reconfigure tdm-trinity
(...)
Has anybody seen this? Do you think it is a bug?
Regards, Stefan
Debian Stretch here. Same thing happened with tha last update/upgrade
Obviously Debian/Devuan got updated too and reset the display manager. As far as I am concerned it's not a bug, just an result of the distribution not respecting modifications by the user and going back to some config file it used for it's own setup.
I my case I found myself loging in from Gnome again.
Thierry
Right, somehow the default display manager got changed to slim? I have only used Debian Stretch and/or Devuan Ascii a little, before reverting to Jessie, but I recall some similar glitches. Somehow it got changed in the update/upgrade.
You can get this back by running dpkg-reconfigure tdm. Otherwise it should come up when you run apt-get to install packages. If you use aptitude, etc., then you may see something else, or maybe it just chooses slim or your most recently installed dm as default. (Also, it occurs to me that tdm comes up as tdm-trinity in some versions, but as just tdm in others; you should be able to pick the right one, in any case.)
Here you are presented with a choice of display managers, depending on what you have installed:
kdm gdm lxdm slim tdm or tdm-trinity xfce
(You probably won't have them all installed.)
Make your choice, hit okay, then you should be back to normal on reboot, unless you have changed something else, or uninstalled or misconfigured something.
Bill
On Tuesday 03 July 2018 12:14:09 J Leslie Turriff wrote:
On 2018-07-03 11:09:21 William Morder wrote:
Here you are presented with a choice of display managers, depending on what you have installed:
kdm gdm lxdm slim tdm or tdm-trinity xfce
What would be the difference between tdm and tdm-trinity?
Leslie
No difference at all, except in name; I seem to recall that it is listed differently in some installations. You will forgive my memory, as it has been a while since I've used other systems (such as Kubuntu, etc.); I believe I am right about this, but maybe not. If not, somebody out there will please correct me!
Right now I'm running Devuan Jessie with Trinity 14.0.5, and just ran both these commands: # dpkg-reconfigure tdm dpkg-reconfigure tdm-trinity ... but only the second one works, so I've commented out the other. The second line is probably right for anybody who has downloaded fairly recent updates. To double-check my memory, however, I just now ran sysv-rc-conf and among my display managers, kdm, slim tdm AND (get this!) tdm-trini$ [sic] comes up; but I only have the lines for tdm marked to start at boot.
It could be that I only believe that I remember the two different variations because it is sort of duplicated in sysv-rc-conf; also, other display managers are simply gdm, kdm, lxdm, slim, etc. Only TDE's entry comes up as the somewhat redundant tdm-trinity.
So I believe that the second choice is probably what you want; although I doubt that you would run into problems by running the other command. Either one or the other will work, but not both. In any case, before you reboot, you can check to see if you have other display managers installed or configured.
The same command will work if you have another dm installed, e.g., dpkg-reconfigure kdm dpkg-reconfigure slim and so on; but not if you don't have them installed. In any case, you choose your display manager from the list, hit return, and when you reboot you ought to see the Trinity Display Manager.
Sorry that this is such a long answer to what ought to be a simple question; but the apparent duplication of tdm and tdm-trinity in some places may be a little confusing.
Bill
J Leslie Turriff wrote:
On 2018-07-03 11:09:21 William Morder wrote:
Here you are presented with a choice of display managers, depending on what you have installed:
kdm gdm lxdm slim tdm or tdm-trinity xfce
What would be the difference between tdm and tdm-trinity?
Leslie
just try
apt-cache show tdm-trinity apt-cache show tdm
I run some kind of experimental release and don't have tdm - might be a meta package, but the apt-cache show command will help you find out
regards
Am Dienstag 03 Juli 2018 schrieb deloptes:
J Leslie Turriff wrote:
On 2018-07-03 11:09:21 William Morder wrote:
Here you are presented with a choice of display managers, depending on what you have installed:
kdm gdm lxdm slim tdm or tdm-trinity xfce
What would be the difference between tdm and tdm-trinity?
Leslie
just try
apt-cache show tdm-trinity apt-cache show tdm
I run some kind of experimental release and don't have tdm - might be a meta package, but the apt-cache show command will help you find out
The name of the package is still "tdm-trinity", but the service and the init file is now called "tdm" in PSB.
Regards, Stefan
Am Dienstag 03 Juli 2018 schrieb Thierry de Coulon:
Debian Stretch here. Same thing happened with tha last update/upgrade
Obviously Debian/Devuan got updated too and reset the display manager. As far as I am concerned it's not a bug, just an result of the distribution not respecting modifications by the user and going back to some config file it used for it's own setup.
I my case I found myself loging in from Gnome again.
Thierry
Thank you. Stefan
On 2018-07-03 09:54:51 Thierry de Coulon wrote:
Obviously Debian/Devuan got updated too and reset the display manager. As far as I am concerned it's not a bug, just an result of the distribution not respecting modifications by the user and going back to some config file it used for it's own setup.
So, not a Trinity bug, but I'd say it could be argued that it's a Debian bug?
Leslie
On Tue, 3 Jul 2018 15:49:06 +0200 Stefan Krusche linux@stefan-krusche.de wrote:
Good day everyone,
I'm using trinity 14.0.5 from preliminary stable builds on devuan ascii (debian stretch).
Through the most recent upgrade, that I executed on 2018-07-02 11:42:01, tdm (amongst a couple others) got upgraded:
tdm-trinity:amd64 (4:14.0.5~pre39-0debian9.0.0+6, 4:14.0.5~pre42-0debi an9.0.0+6)
After this upgrade tdm wouldn't start anymore and in /var/log/boot I found this error message:
Not starting Trinity Display Manager (tdm); it is not the default display manager.
The file is there: $ ls -l /etc/X11/default-display-manager -rw-r--r-- 1 root root 14 Jul 2 11:42 /etc/X11/default-display-manager
And it says: $ cat /etc/X11/default-display-manager /usr/bin/slim
Solution:
$ dpkg-reconfigure tdm-trinity
Of course, tdm was the default display manager already before the upgrade, and, as you can guess from the above, slim is installed, too.
I think, it should not be necessary to reconfigure the display manager, or, least, the user should be prompted to do so at installation.
IIRC, this happened already at the previous upgrade to ~pre39.
Has anybody seen this? Do you think it is a bug?
First, a you sure that slim wasnt updated too? Because if it was it is most likely bug in slim. If not than this looks like a problem with debconf database (or a bug in debconf). Look in /var/cache/debconf/config.dat for shared/default-x-display-manager and post a context of this section
On 07/03/2018 08:12 AM, Nick Koretsky wrote:
On Tue, 3 Jul 2018 15:49:06 +0200 Stefan Krusche linux@stefan-krusche.de wrote:
Good day everyone,
I'm using trinity 14.0.5 from preliminary stable builds on devuan ascii (debian stretch).
Through the most recent upgrade, that I executed on 2018-07-02 11:42:01, tdm (amongst a couple others) got upgraded:
tdm-trinity:amd64 (4:14.0.5~pre39-0debian9.0.0+6, 4:14.0.5~pre42-0debi an9.0.0+6)
After this upgrade tdm wouldn't start anymore and in /var/log/boot I found this error message:
Not starting Trinity Display Manager (tdm); it is not the default display manager.
The file is there: $ ls -l /etc/X11/default-display-manager -rw-r--r-- 1 root root 14 Jul 2 11:42 /etc/X11/default-display-manager
And it says: $ cat /etc/X11/default-display-manager /usr/bin/slim
Solution:
$ dpkg-reconfigure tdm-trinity
Of course, tdm was the default display manager already before the upgrade, and, as you can guess from the above, slim is installed, too.
I think, it should not be necessary to reconfigure the display manager, or, least, the user should be prompted to do so at installation.
IIRC, this happened already at the previous upgrade to ~pre39.
Has anybody seen this? Do you think it is a bug?
First, a you sure that slim wasnt updated too? Because if it was it is most likely bug in slim. If not than this looks like a problem with debconf database (or a bug in debconf). Look in /var/cache/debconf/config.dat for shared/default-x-display-manager and post a context of this section
There is no logical reason to have two DM's, simple solution, remove one or the other and there is no problem.
Hi Nick,
thank you. I looked after that.
Am Dienstag 03 Juli 2018 schrieb Nick Koretsky:
First, a you sure that slim wasnt updated too? Because if it was it is most likely bug in slim. If not than this looks like a problem with debconf database (or a bug in debconf).
As to what is logged in /var/log/aptitude, slim was only once installed when I set up the system.
--> /var/log/apt/history.log says this about slim and tdm-trinity:
Start-Date: 2018-06-03 23:03:03 Install: [...], tdm-trinity:amd64 (4:14.0.5~pre36-0debian9.0.0+6), [...]
Start-Date: 2018-06-04 15:04:08 Install: [...], slim:amd64 (1.3.6-5.1+devuan2), [...]
Start-Date: 2018-06-28 16:15:17 Upgrade: [...], tdm-trinity:amd64 (4:14.0.5~pre36-0debian9.0.0+6, 4:14.0.5~pre39-0debian9.0.0+6), [...]
Start-Date: 2018-07-02 11:42:01 Upgrade: [...], tdm-trinity:amd64 (4:14.0.5~pre39-0debian9.0.0+6, 4:14.0.5~pre42-0debian9.0.0+6), [...]
When I upgraded tdm-trinity the first time from "~pre36" to "~pre39", after slim had been installed, the problem appeared, that the default display-manager got changed.
That's why I was thinking it might have something to do with package tdm-trinity. But I don't understand this whole update and configuration process sufficiently enough, that I really could tell. And, yes, could have something to do with slim package as well.
Look in /var/cache/debconf/config.dat for shared/default-x-display-manager and post a context of this section
Alright, /var/cache/debconf/config.dat is from 2018-07-03 15:27:28, probably when I manually reconfigured display-manager, and not from when I did the upgrade on 2018-07-02 11:42:01. This is in it:
$ grep -n -A1 -B1 -E "tdm|slim" config.dat 756-Template: shared/default-x-display-manager 757:Value: tdm-trinity 758:Owners: slim, tdm-trinity 759-Flags: seen 760-Variables: 761: choices = slim, tdm-trinity 762- -- 784- 785:Name: slim/daemon_name 786:Template: slim/daemon_name 787:Owners: slim 788- -- 812- 813:Name: tdm-trinity/daemon_name 814:Template: tdm-trinity/daemon_name 815:Owners: tdm-trinity 816- 817:Name: tdm-trinity/stop_running_server_with_children 818:Template: tdm-trinity/stop_running_server_with_children 819:Owners: tdm-trinity 820-
What can you get out of this?
Regards, Stefan
On Wed, 4 Jul 2018 13:48:41 +0200 Stefan Krusche linux@stefan-krusche.de wrote:
When I upgraded tdm-trinity the first time from "~pre36" to "~pre39", after slim had been installed, the problem appeared, that the default display-manager got changed.
That's why I was thinking it might have something to do with package tdm-trinity. But I don't understand this whole update and configuration process sufficiently enough, that I really could tell. And, yes, could have something to do with slim package as well.
Look in /var/cache/debconf/config.dat for shared/default-x-display-manager and post a context of this section
Alright, /var/cache/debconf/config.dat is from 2018-07-03 15:27:28, probably when I manually reconfigured display-manager, and not from when I did the upgrade on 2018-07-02 11:42:01. This is in it:
$ grep -n -A1 -B1 -E "tdm|slim" config.dat 756-Template: shared/default-x-display-manager 757:Value: tdm-trinity 758:Owners: slim, tdm-trinity 759-Flags: seen 760-Variables: 761: choices = slim, tdm-trinity 762- -- What can you get out of this?
Ok, this looks normal. At this point if you want to track down the bug, i suggest following:
Force reinstall tdm-trinity (unless you clean apt-cache the package is in /var/cache/apt/archives, just dpkg -i the last version.
If default dm stays tdm-trinity after that than i have absolutely no idea what happened. Maybe whatever program you used to update (apt? apt-get? aptitude? some gui?) calls dpkg in some weird way, but its hard to track this - downgrade to a previous version and upgrade again using different programs?
If it changed to slim - Force reinstall slim.
If default dm remained slim after that than this is a bug in tdm-trinity install scripts, create a bug report in trinity bugzilla.
If it changed back to tdm-trinity than this is a bug in dpkg (probably devuan one, as i dont have this problem on stretch). Report this to devuan.
Am Mittwoch 04 Juli 2018 schrieb Nick Koretsky:
On Wed, 4 Jul 2018 13:48:41 +0200
Stefan Krusche linux@stefan-krusche.de wrote:
Alright, /var/cache/debconf/config.dat is from 2018-07-03 15:27:28, probably when I manually reconfigured display-manager, and not from when I did the upgrade on 2018-07-02 11:42:01. This is in it:
$ grep -n -A1 -B1 -E "tdm|slim" config.dat 756-Template: shared/default-x-display-manager 757:Value: tdm-trinity 758:Owners: slim, tdm-trinity 759-Flags: seen 760-Variables: 761: choices = slim, tdm-trinity 762- -- What can you get out of this?
Ok, this looks normal. At this point if you want to track down the bug, i suggest following:
Force reinstall tdm-trinity (unless you clean apt-cache the package is in /var/cache/apt/archives, just dpkg -i the last version.
If default dm stays tdm-trinity after that than i have absolutely no idea what happened. Maybe whatever program you used to update (apt? apt-get? aptitude? some gui?) calls dpkg in some weird way, but its hard to track this - downgrade to a previous version and upgrade again using different programs?
If it changed to slim - Force reinstall slim.
If default dm remained slim after that than this is a bug in tdm-trinity install scripts, create a bug report in trinity bugzilla.
If it changed back to tdm-trinity than this is a bug in dpkg (probably devuan one, as i dont have this problem on stretch). Report this to devuan.
Alright, thanks. I'll keep on digging. Stefan
Am Mittwoch, 4. Juli 2018 schrieb Nick Koretsky:
Ok, this looks normal. At this point if you want to track down the bug, i suggest following:
Force reinstall tdm-trinity (unless you clean apt-cache the package is in /var/cache/apt/archives, just dpkg -i the last version.
Okay, I tested that. Here are the results:
Summary: Installing either slim or tdm-trinity overwrites the default display manager to /usr/bin/slim not depending on the way I changed default dm, manually or with dpkg-reconfigure.
Note: dpkg-reconfigure slim says: Please be sure to run "dpkg --configure tdm-trinity".
But also after doing so, the faulty behavior persists. See below.
So, I should create a bug report in trinity bugzilla, I think.
Kind regards, Stefan
Test results:
Reinstalling tdm-trinity: $ cat /etc/X11/default-display-manager /opt/trinity/bin/tdm
$ sudo dpkg -i tdm-trinity_4%3a14.0.5~pre42-0debian9.0.0+6_amd64.deb (Reading database ... 156996 files and directories currently installed.) Preparing to unpack tdm-trinity_4%3a14.0.5~pre42-0debian9.0.0+6_amd64.deb ... Unpacking tdm-trinity (4:14.0.5~pre42-0debian9.0.0+6) over (4:14.0.5~pre42-0debian9.0.0+6) ... Setting up tdm-trinity (4:14.0.5~pre42-0debian9.0.0+6) ... Processing triggers for man-db (2.7.6.1-2) ...
$ cat /etc/X11/default-display-manager /usr/bin/slim
Result: The default display manager got changed to slim again.
$ sudo dpkg -i slim_1.3.6-5.1+devuan2_amd64.deb (Reading database ... 156996 files and directories currently installed.) Preparing to unpack slim_1.3.6-5.1+devuan2_amd64.deb ... Unpacking slim (1.3.6-5.1+devuan2) over (1.3.6-5.1+devuan2) ... Setting up slim (1.3.6-5.1+devuan2) ... update-alternatives: using /usr/share/slim/themes/default to provide /usr/share/slim/themes/desktop-slim-theme (desktop-slim-theme) in auto mode [ ok ] Reloading system message bus config...done. Processing triggers for man-db (2.7.6.1-2) ...
$ cat /etc/X11/default-display-manager /usr/bin/slim
Result: default display manager is slim as before
Reinstalling tdm-trinity -- /etc/X11/default-display-manager not changed: $ sudo dpkg -i tdm-trinity_4%3a14.0.5~pre42-0debian9.0.0+6_amd64.deb [...] (same as above) $ cat /etc/X11/default-display-manager /usr/bin/slim
(Manually) changed /etc/X11/default-display-manager back to tdm-trinity
$ cat /etc/X11/default-display-manager /opt/trinity/bin/tdm
and reinstalled slim: $ sudo dpkg -i slim_1.3.6-5.1+devuan2_amd64.deb [...] (same as above) $ cat /etc/X11/default-display-manager /usr/bin/slim
Result: installing slim changed default display manager to slim !
$ sudo dpkg-reconfigure tdm-trinity $ cat /etc/X11/default-display-manager /opt/trinity/bin/tdm
$ sudo dpkg -i tdm-trinity_4%3a14.0.5~pre42-0debian9.0.0+6_amd64.deb [...] (same as above) $ cat /etc/X11/default-display-manager /usr/bin/slim
$ sudo dpkg-reconfigure slim Please be sure to run "dpkg --configure tdm-trinity". [ ok ] Reloading system message bus config...done. $ cat /etc/X11/default-display-manager /opt/trinity/bin/tdm
$ sudo dpkg -i tdm-trinity_4%3a14.0.5~pre42-0debian9.0.0+6_amd64.deb [...] (same as above) $ cat /etc/X11/default-display-manager /usr/bin/slim
$ sudo dpkg-reconfigure slim Please be sure to run "dpkg --configure tdm-trinity". [ ok ] Reloading system message bus config...done. $ sudo dpkg-reconfigure tdm-trinity $ cat /etc/X11/default-display-manager /opt/trinity/bin/tdm
$ sudo dpkg -i tdm-trinity_4%3a14.0.5~pre42-0debian9.0.0+6_amd64.deb [...] (same as above) $ cat /etc/X11/default-display-manager /usr/bin/slim
$ sudo dpkg-reconfigure slim Please be sure to run "dpkg --configure tdm-trinity". [ ok ] Reloading system message bus config...done. $ cat /etc/X11/default-display-manager /opt/trinity/bin/tdm
$ sudo dpkg -i slim_1.3.6-5.1+devuan2_amd64.deb [...] (same as above) $ cat /etc/X11/default-display-manager /usr/bin/slim
On Saturday 14 July 2018 14:38:56 Stefan Krusche wrote:
Am Mittwoch, 4. Juli 2018 schrieb Nick Koretsky:
Ok, this looks normal. At this point if you want to track down the bug, i suggest following:
Force reinstall tdm-trinity (unless you clean apt-cache the package is in /var/cache/apt/archives, just dpkg -i the last version.
Okay, I tested that. Here are the results:
Summary: Installing either slim or tdm-trinity overwrites the default display manager to /usr/bin/slim not depending on the way I changed default dm, manually or with dpkg-reconfigure.
Note: dpkg-reconfigure slim says: Please be sure to run "dpkg --configure tdm-trinity".
But also after doing so, the faulty behavior persists. See below.
So, I should create a bug report in trinity bugzilla, I think.
Kind regards, Stefan
Test results:
Reinstalling tdm-trinity: $ cat /etc/X11/default-display-manager /opt/trinity/bin/tdm
$ sudo dpkg -i tdm-trinity_4%3a14.0.5~pre42-0debian9.0.0+6_amd64.deb (Reading database ... 156996 files and directories currently installed.) Preparing to unpack tdm-trinity_4%3a14.0.5~pre42-0debian9.0.0+6_amd64.deb ... Unpacking tdm-trinity (4:14.0.5~pre42-0debian9.0.0+6) over (4:14.0.5~pre42-0debian9.0.0+6) ... Setting up tdm-trinity (4:14.0.5~pre42-0debian9.0.0+6) ... Processing triggers for man-db (2.7.6.1-2) ...
$ cat /etc/X11/default-display-manager /usr/bin/slim
Result: The default display manager got changed to slim again.
$ sudo dpkg -i slim_1.3.6-5.1+devuan2_amd64.deb (Reading database ... 156996 files and directories currently installed.) Preparing to unpack slim_1.3.6-5.1+devuan2_amd64.deb ... Unpacking slim (1.3.6-5.1+devuan2) over (1.3.6-5.1+devuan2) ... Setting up slim (1.3.6-5.1+devuan2) ... update-alternatives: using /usr/share/slim/themes/default to provide /usr/share/slim/themes/desktop-slim-theme (desktop-slim-theme) in auto mode [ ok ] Reloading system message bus config...done. Processing triggers for man-db (2.7.6.1-2) ...
$ cat /etc/X11/default-display-manager /usr/bin/slim
Result: default display manager is slim as before
Reinstalling tdm-trinity -- /etc/X11/default-display-manager not changed: $ sudo dpkg -i tdm-trinity_4%3a14.0.5~pre42-0debian9.0.0+6_amd64.deb [...] (same as above) $ cat /etc/X11/default-display-manager /usr/bin/slim
(Manually) changed /etc/X11/default-display-manager back to tdm-trinity
$ cat /etc/X11/default-display-manager /opt/trinity/bin/tdm
and reinstalled slim: $ sudo dpkg -i slim_1.3.6-5.1+devuan2_amd64.deb [...] (same as above) $ cat /etc/X11/default-display-manager /usr/bin/slim
Result: installing slim changed default display manager to slim !
$ sudo dpkg-reconfigure tdm-trinity $ cat /etc/X11/default-display-manager /opt/trinity/bin/tdm
$ sudo dpkg -i tdm-trinity_4%3a14.0.5~pre42-0debian9.0.0+6_amd64.deb [...] (same as above) $ cat /etc/X11/default-display-manager /usr/bin/slim
$ sudo dpkg-reconfigure slim Please be sure to run "dpkg --configure tdm-trinity". [ ok ] Reloading system message bus config...done. $ cat /etc/X11/default-display-manager /opt/trinity/bin/tdm
$ sudo dpkg -i tdm-trinity_4%3a14.0.5~pre42-0debian9.0.0+6_amd64.deb [...] (same as above) $ cat /etc/X11/default-display-manager /usr/bin/slim
$ sudo dpkg-reconfigure slim Please be sure to run "dpkg --configure tdm-trinity". [ ok ] Reloading system message bus config...done. $ sudo dpkg-reconfigure tdm-trinity $ cat /etc/X11/default-display-manager /opt/trinity/bin/tdm
$ sudo dpkg -i tdm-trinity_4%3a14.0.5~pre42-0debian9.0.0+6_amd64.deb [...] (same as above) $ cat /etc/X11/default-display-manager /usr/bin/slim
$ sudo dpkg-reconfigure slim Please be sure to run "dpkg --configure tdm-trinity". [ ok ] Reloading system message bus config...done. $ cat /etc/X11/default-display-manager /opt/trinity/bin/tdm
$ sudo dpkg -i slim_1.3.6-5.1+devuan2_amd64.deb [...] (same as above) $ cat /etc/X11/default-display-manager /usr/bin/slim
From these details, I assume that you are running Devuan. I was just about to write something about similar problems that I have had over the past week or ten days. When I run apt-get dist-upgrade (running Devuan), it installs slim and xfce (neither of which I want), as well as libreoffice packages (which I also don't want, as I prefer OpenOffice). When I tried to get rid of these items and reinstall only OpenOffice and tdm-trinity as my default dm, I ended up with a system that booted, then halted at a login prompt; I tried to login, but neither user nor root logins worked, and I couldn't boot into failsafe or anything else that worked.
On the whole, Devuan runs much faster than Debian, and also my system doesn't hang. I started having these and other problems, and returned for the moment to Debian Jessie, which runs okay, but hangs a lot, and when I try to reboot seems to get permanently stuck on some stuff called rpcbind and watchdog. (Also I note that systemd is always doing something, don't know what.)
I am contemplating some kind of FrankenDebian hack (or rather, FrankenDevuan). I seem to recall that somebody mentioned that sysvinit could be installed, and systemd purged, on a Debian system. The do upgrades from the Debian repositories, but keep sysvinit and avoid the systemd problems.
Any ideas, guys?
Bill
Am Sonntag, 15. Juli 2018 schrieb William Morder:
From these details, I assume that you are running Devuan.
Nothing to assume here, I revealed that in my original post. ;-)
I was just about to write something about similar problems that I have had over the past week or ten days. When I run apt-get dist-upgrade (running Devuan), it installs slim and xfce (neither of which I want), as well as libreoffice packages (which I also don't want, as I prefer OpenOffice). When I tried to get rid of these items and reinstall only OpenOffice and tdm-trinity as my default dm, I ended up with a system that booted, then halted at a login prompt; I tried to login, but neither user nor root logins worked, and I couldn't boot into failsafe or anything else that worked.
This probably depends on what state your system was in before upgrading, that is, which packages were installed and if they were installed manually or by which dependency etc., which is unclear by the information you provide, so either it's a Devuan-related issue or based on what you have done. It has nothing to do with the problem I reported.
On the whole, Devuan runs much faster than Debian, and also my system doesn't hang. I started having these and other problems, and returned for the moment to Debian Jessie, which runs okay, but hangs a lot, and when I try to reboot seems to get permanently stuck on some stuff called rpcbind and watchdog. (Also I note that systemd is always doing something, don't know what.)
I am contemplating some kind of FrankenDebian hack (or rather, FrankenDevuan). I seem to recall that somebody mentioned that sysvinit could be installed, and systemd purged, on a Debian system. The do upgrades from the Debian repositories, but keep sysvinit and avoid the systemd problems.
Any ideas, guys?
Outline your problem(s) precisely and start a new thread or maybe post to devuan list.
Kind regards, Stefan
On Sat July 14 2018 15:03:46 William Morder wrote:
From these details, I assume that you are running Devuan. I was just about to write something about similar problems that I have had over the past week or ten days. When I run apt-get dist-upgrade (running Devuan), it installs slim and xfce (neither of which I want), as well as libreoffice packages (which I also don't want, as I prefer OpenOffice).
After your unwanted slim, xfce, and libreoffice are installed what are the results of running "apt-cache rdepends slim", "aptitude why slim" etc.
OpenOffice appears to be obsolete. I'm not sure what source of OpenOffice packages you are using but they may not satisfy today's dependencies. What does "apt-cache policy openoffice" (or whatever your primary openoffice package is called) report?
When I tried to get rid of these items and reinstall only OpenOffice and tdm-trinity as my default dm, I ended up with a system that booted, then halted at a login prompt; I tried to login, but neither user nor root logins worked, and I couldn't boot into failsafe or anything else that worked.
Possibly a long time known slim bug that it stays on as default display manager even after uninstalling.
Aside #1: We don't have these problems but we use LibreOffice. The messy interface of LibreOffice 5 is a distinct downgrade from earlier versions but at least we get security updates.
Aside #2: I'm struggling to see how this has any relevance to Trinity.
--Mike
On Sat, 14 Jul 2018 15:03:46 -0700 William Morder doctor_contendo@zoho.com wrote:
On the whole, Devuan runs much faster than Debian, and also my system doesn't hang. I started having these and other problems, and returned for the moment to Debian Jessie, which runs okay, but hangs a lot, and when I try to reboot seems to get permanently stuck on some stuff called rpcbind and watchdog. (Also I note that systemd is always doing something, don't know what.)
I am contemplating some kind of FrankenDebian hack (or rather, FrankenDevuan). I seem to recall that somebody mentioned that sysvinit could be installed, and systemd purged, on a Debian system. The do upgrades from the Debian repositories, but keep sysvinit and avoid the systemd problems.
This depend on what level you want to purge systemd. If it is not for ideological reasons and you are ok with having all sysytemd libraries in system, just want sysvinit as pid 1, then you just need to install sysvinit-core and uninstall systemd-sysv.
On Saturday 14 July 2018 16:28:18 Nick Koretsky wrote:
On Sat, 14 Jul 2018 15:03:46 -0700
William Morder doctor_contendo@zoho.com wrote:
On the whole, Devuan runs much faster than Debian, and also my system doesn't hang. I started having these and other problems, and returned for the moment to Debian Jessie, which runs okay, but hangs a lot, and when I try to reboot seems to get permanently stuck on some stuff called rpcbind and watchdog. (Also I note that systemd is always doing something, don't know what.)
I am contemplating some kind of FrankenDebian hack (or rather, FrankenDevuan). I seem to recall that somebody mentioned that sysvinit could be installed, and systemd purged, on a Debian system. The do upgrades from the Debian repositories, but keep sysvinit and avoid the systemd problems.
This depend on what level you want to purge systemd. If it is not for ideological reasons and you are ok with having all sysytemd libraries in system, just want sysvinit as pid 1, then you just need to install sysvinit-core and uninstall systemd-sysv.
Thanks, I believe that answers my question. I've already seen Devuan running more or less like this, and it seemed to do okay. I am not "against" systemd for ideological reasons; I only want my system to run smoothly and efficiently, not to hang up, that kind of thing; and something like this would seem to be my solution, at least temporarily.
As for getting off-topic, I will drop it for now, as I have got my own answer, and leave others to work out these other issues that don't concern me.
Bill
On Sat, 14 Jul 2018 19:50:38 -0700 William Morder doctor_contendo@zoho.com wrote:
On the whole, Devuan runs much faster than Debian, and also my system doesn't hang. I started having these and other problems, and returned for the moment to Debian Jessie, which runs okay, but hangs a lot, and when I try to reboot seems to get permanently stuck on some stuff called rpcbind and watchdog. (Also I note that systemd is always doing something, don't know what.)
I am contemplating some kind of FrankenDebian hack (or rather, FrankenDevuan). I seem to recall that somebody mentioned that sysvinit could be installed, and systemd purged, on a Debian system. The do upgrades from the Debian repositories, but keep sysvinit and avoid the systemd problems.
This depend on what level you want to purge systemd. If it is not for ideological reasons and you are ok with having all sysytemd libraries in system, just want sysvinit as pid 1, then you just need to install sysvinit-core and uninstall systemd-sysv.
Thanks, I believe that answers my question. I've already seen Devuan running more or less like this, and it seemed to do okay. I am not "against" systemd for ideological reasons; I only want my system to run smoothly and efficiently, not to hang up, that kind of thing; and something like this would seem to be my solution, at least temporarily.
As for getting off-topic, I will drop it for now, as I have got my own answer, and leave others to work out these other issues that don't concern me.
BTW, a trick to prevent systemd accidentally getting reinstalled as pid 1 on updates - create a file in /etc/apt/preferences.d with following content:
Package: systemd-sysv Pin: release o=Debian Pin-Priority: -1
On Sunday 15 July 2018 01:34:01 Nick Koretsky wrote:
On Sat, 14 Jul 2018 19:50:38 -0700
William Morder doctor_contendo@zoho.com wrote:
On the whole, Devuan runs much faster than Debian, and also my system doesn't hang. I started having these and other problems, and returned for the moment to Debian Jessie, which runs okay, but hangs a lot, and when I try to reboot seems to get permanently stuck on some stuff called rpcbind and watchdog. (Also I note that systemd is always doing something, don't know what.)
I am contemplating some kind of FrankenDebian hack (or rather, FrankenDevuan). I seem to recall that somebody mentioned that sysvinit could be installed, and systemd purged, on a Debian system. The do upgrades from the Debian repositories, but keep sysvinit and avoid the systemd problems.
This depend on what level you want to purge systemd. If it is not for ideological reasons and you are ok with having all sysytemd libraries in system, just want sysvinit as pid 1, then you just need to install sysvinit-core and uninstall systemd-sysv.
Thanks, I believe that answers my question. I've already seen Devuan running more or less like this, and it seemed to do okay. I am not "against" systemd for ideological reasons; I only want my system to run smoothly and efficiently, not to hang up, that kind of thing; and something like this would seem to be my solution, at least temporarily.
As for getting off-topic, I will drop it for now, as I have got my own answer, and leave others to work out these other issues that don't concern me.
BTW, a trick to prevent systemd accidentally getting reinstalled as pid 1 on updates - create a file in /etc/apt/preferences.d with following content:
Package: systemd-sysv Pin: release o=Debian Pin-Priority: -1
Thanks to those recent tips from deloptes and Nick Koretsky, my system is now purring like a kitten.
And I did find a file called avoid-systemd in that folder, so I copied it for backup.
Bill
William Morder wrote:
I am contemplating some kind of FrankenDebian hack (or rather, FrankenDevuan). I seem to recall that somebody mentioned that sysvinit could be installed, and systemd purged, on a Debian system. The do upgrades from the Debian repositories, but keep sysvinit and avoid the systemd problems.
I discussed this in the debian user list. I was pointed out that installing sysv* (don't know exactly which one) replaces systemd as init process. I have installed ii sysv-rc 2.88dsf-59.9 all System-V-like runlevel change mechanism ii sysvinit-core 2.88dsf-59.9 amd64 System-V-like init utilities ii sysvinit-utils 2.88dsf-59.9 amd64 System-V-like utilities
systemd is still there, but it is not the init process and all works just fine.
ii dbus-user-session 1.10.26-0+deb9u1 all simple interprocess messaging system (systemd --user integration) ii libpam-systemd:amd64 232-25+deb9u3 amd64 system and service manager - PAM module ii libsystemd0:amd64 232-25+deb9u3 amd64 systemd utility library ii libsystemd0:i386 232-25+deb9u3 i386 systemd utility library ii systemd 232-25+deb9u3 amd64 system and service manager ii systemd-shim 10-3 amd64 shim for systemd
I am pretty happy with this setup.
regards
On Saturday 14 July 2018 23:41:36 deloptes wrote:
William Morder wrote:
I am contemplating some kind of FrankenDebian hack (or rather, FrankenDevuan). I seem to recall that somebody mentioned that sysvinit could be installed, and systemd purged, on a Debian system. The do upgrades from the Debian repositories, but keep sysvinit and avoid the systemd problems.
I discussed this in the debian user list. I was pointed out that installing sysv* (don't know exactly which one) replaces systemd as init process. I have installed ii sysv-rc 2.88dsf-59.9 all System-V-like runlevel change mechanism ii sysvinit-core 2.88dsf-59.9 amd64 System-V-like init utilities ii sysvinit-utils 2.88dsf-59.9 amd64 System-V-like utilities
systemd is still there, but it is not the init process and all works just fine.
ii dbus-user-session 1.10.26-0+deb9u1 all simple interprocess messaging system (systemd --user integration) ii libpam-systemd:amd64 232-25+deb9u3 amd64 system and service manager - PAM module ii libsystemd0:amd64 232-25+deb9u3 amd64 systemd utility library ii libsystemd0:i386 232-25+deb9u3 i386 systemd utility library ii systemd 232-25+deb9u3 amd64 system and service manager ii systemd-shim 10-3 amd64 shim for systemd
I am pretty happy with this setup.
regards
Right, that's where I am headed. I noticed that my Devuan system ran pretty well before I uninstalled other systemd processes. If not for these bugs (or whatever they are) that seem to be something new in Devuan, I was liking Devuan better than Debian.
If it didn't involve breaking some rules and the risk of wrecking one's system, they wouldn't call it hacking. :-] Well, anyway, I have been hacking away on my own computers since about 1980-81; and when I briefly studied computer programming in the 1970s, it meant IBM punch cards. So I am not afraid of making a mess of things. It can always be restored.
Thanks for this information, as it will help me find my way. I have a lot of Devuan packages that I've saved, but it's good to know what works for other people.
Bill
On Sat July 14 2018 14:38:56 Stefan Krusche wrote:
Summary: Installing either slim or tdm-trinity overwrites the default display manager to /usr/bin/slim not depending on the way I changed default dm, manually or with dpkg-reconfigure.
Note: dpkg-reconfigure slim says: Please be sure to run "dpkg --configure tdm-trinity".
But also after doing so, the faulty behavior persists. See below.
So, I should create a bug report in trinity bugzilla, I think.
Slim has had bugs in this area for years, e.g.:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580838
I don't see what this has to do with Trinity.
--Mike
On Saturday 14 July 2018 15:44:19 Mike Bird wrote:
On Sat July 14 2018 14:38:56 Stefan Krusche wrote:
Summary: Installing either slim or tdm-trinity overwrites the default display manager to /usr/bin/slim not depending on the way I changed default dm, manually or with dpkg-reconfigure.
Note: dpkg-reconfigure slim says: Please be sure to run "dpkg --configure tdm-trinity".
But also after doing so, the faulty behavior persists. See below.
So, I should create a bug report in trinity bugzilla, I think.
Slim has had bugs in this area for years, e.g.:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580838
I don't see what this has to do with Trinity.
--Mike
I think it's just that slim gets installed (or configured) as our default display manager, regardless what we do. On Devuan, anyway, that's what started happening to me. Maybe it's happening in Debian, too.
It indirectly affects Trinity, if we cannot get tdm-trinity as our default display manager.
Bill
On Sat July 14 2018 15:53:11 William Morder wrote:
It indirectly affects Trinity, if we cannot get tdm-trinity as our default display manager.
Bugs that affect Trinity are not necessarily Trinity bugs.
The Debian packaging of Slim has been known to mishandle default display manager information for more than eight years, and this affects all display managers not just Trinity. (I did not know this before half a minute of searching today.)
I hope we can keep this Trinity list on topic.
--Mike
Am Sonntag, 15. Juli 2018 schrieb Mike Bird:
On Sat July 14 2018 14:38:56 Stefan Krusche wrote:
Summary: Installing either slim or tdm-trinity overwrites the default display manager to /usr/bin/slim not depending on the way I changed default dm, manually or with dpkg-reconfigure.
Note: dpkg-reconfigure slim says: Please be sure to run "dpkg --configure tdm-trinity".
But also after doing so, the faulty behavior persists. See below.
So, I should create a bug report in trinity bugzilla, I think.
Slim has had bugs in this area for years, e.g.:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580838
I don't see what this has to do with Trinity.
Alright, thanks, that throws a different light on the issue.
Stefan
On Sat, 14 Jul 2018 23:38:56 +0200 Stefan Krusche linux@stefan-krusche.de wrote:
Am Mittwoch, 4. Juli 2018 schrieb Nick Koretsky:
Ok, this looks normal. At this point if you want to track down the bug, i suggest following:
Force reinstall tdm-trinity (unless you clean apt-cache the package is in /var/cache/apt/archives, just dpkg -i the last version.
Okay, I tested that. Here are the results:
Summary: Installing either slim or tdm-trinity overwrites the default display manager to /usr/bin/slim not depending on the way I changed default dm, manually or with dpkg-reconfigure.
Note: dpkg-reconfigure slim says: Please be sure to run "dpkg --configure tdm-trinity".
But also after doing so, the faulty behavior persists. See below.
So, I should create a bug report in trinity bugzilla, I think.
Um, no. This 99% not trinity bug. Your test result indicate bug in either in dpkg or debconf, and considering i dont have this problem on debian stretch it is probably a devuan introduced bug.
Am Sonntag, 15. Juli 2018 schrieb Nick Koretsky:
Um, no. This 99% not trinity bug. Your test result indicate bug in either in dpkg or debconf, and considering i dont have this problem on debian stretch it is probably a devuan introduced bug.
I think I misunderstood your previous mail on 04.07.2018 from which I concluded after I did the testing that it is a bug in tdm-trinity install scripts.
If it changed to slim - Force reinstall slim.
If default dm remained slim after that than this is a bug in tdm-trinity install scripts, create a bug report in trinity bugzilla.
That is what happened in all my tests.
If it changed back to tdm-trinity
That happened in none of my tests.
Also I found an old bug report (#36) on trinity bugzilla[1] which described the same problem with gdm and kdm-kde3 packages and which had been closed "due to lack of response". That assured me somehow of having run into the same one.
than this is a bug in dpkg (probably devuan one, as i dont have this problem on stretch). Report this to devuan.
The slim package has been adopted by devuan. After all, I think you're right. Thanks again.
Kind regards, Stefan
On Sun, 15 Jul 2018 02:04:07 +0200 Stefan Krusche linux@stefan-krusche.de wrote:
Am Sonntag, 15. Juli 2018 schrieb Nick Koretsky:
Um, no. This 99% not trinity bug. Your test result indicate bug in either in dpkg or debconf, and considering i dont have this problem on debian stretch it is probably a devuan introduced bug.
I think I misunderstood your previous mail on 04.07.2018 from which I concluded after I did the testing that it is a bug in tdm-trinity install scripts.
If it changed to slim - Force reinstall slim.
If default dm remained slim after that than this is a bug in tdm-trinity install scripts, create a bug report in trinity bugzilla.
That is what happened in all my tests.
If it changed back to tdm-trinity
That happened in none of my tests.
Yep i missed the case with reinstalling slim while tdm is a default. That change to slim cannot happen as a result if tdm-trinity bug. It is also cannot be a bug in slim because a change happens while reinstalling tdm. This is a bug in debconf probably but maybe in dpkg. Well theoretically there is a possibility that there are bugs in both slim and tdm-trinity packages...
Also I found an old bug report (#36) on trinity bugzilla[1] which described the same problem with gdm and kdm-kde3 packages and which had been closed "due to lack of response". That assured me somehow of having run into the same one.
than this is a bug in dpkg (probably devuan one, as i dont have this problem on stretch). Report this to devuan.
The slim package has been adopted by devuan. After all, I think you're right. Thanks again.
On Saturday 14 July 2018 17:15:02 Nick Koretsky wrote:
On Sun, 15 Jul 2018 02:04:07 +0200
Stefan Krusche linux@stefan-krusche.de wrote:
Am Sonntag, 15. Juli 2018 schrieb Nick Koretsky:
Um, no. This 99% not trinity bug. Your test result indicate bug in either in dpkg or debconf, and considering i dont have this problem on debian stretch it is probably a devuan introduced bug.
I think I misunderstood your previous mail on 04.07.2018 from which I concluded after I did the testing that it is a bug in tdm-trinity install scripts.
If it changed to slim - Force reinstall slim.
If default dm remained slim after that than this is a bug in tdm-trinity install scripts, create a bug report in trinity bugzilla.
That is what happened in all my tests.
If it changed back to tdm-trinity
That happened in none of my tests.
Yep i missed the case with reinstalling slim while tdm is a default. That change to slim cannot happen as a result if tdm-trinity bug. It is also cannot be a bug in slim because a change happens while reinstalling tdm. This is a bug in debconf probably but maybe in dpkg. Well theoretically there is a possibility that there are bugs in both slim and tdm-trinity packages...
Also I found an old bug report (#36) on trinity bugzilla[1] which described the same problem with gdm and kdm-kde3 packages and which had been closed "due to lack of response". That assured me somehow of having run into the same one.
than this is a bug in dpkg (probably devuan one, as i dont have this problem on stretch). Report this to devuan.
The slim package has been adopted by devuan. After all, I think you're right. Thanks again.
Sorry, got to add my 2 cents' worth here. I believe that this must be a Devuan bug; there could be problems with slim and tdm-trinity, although I think it is immaterial to my point here.
The reason I would trace it to Devuan is that I only ever ran apt-get dist-upgrade; I never tried to install slim or xfce, nor libreoffice, etc., but these were installed automatically. I had assumed, wrongly, that I would get only upgrades of what was already installed.
For about three months previously, I had made no changes whatsoever to my system, except periodically to run apt-get dist-upgrade; then suddenly I get these extra packages installed. That's why I say it must be a Devuan bug, and maybe a recent bug.
It looks like some of us need to join a Devuan mailing list, as well.
Bill
On Sat July 14 2018 20:38:56 William Morder wrote:
Sorry, got to add my 2 cents' worth here. I believe that this must be a Devuan bug; there could be problems with slim and tdm-trinity, although I think it is immaterial to my point here.
The reason I would trace it to Devuan is that I only ever ran apt-get dist-upgrade; I never tried to install slim or xfce, nor libreoffice, etc., but these were installed automatically. I had assumed, wrongly, that I would get only upgrades of what was already installed.
To upgrade existing packages use "apt-get update && apt-get upgrade".
"apt-get dist-upgrade" is only required in complex situations, e.g. where other packages must be added or removed to accommodate package upgrades. This normally only happens when upgrading to a new release.
Whenever "apt-get dist-upgrade" is needed it is important to carefully check what apt-get proposes to do and determine to your own satisfaction that the proposed actions are sensible, safe, and appropriate.
The information from "apt-get rdepends ..." and/or "aptitude why ..." is the first step on the road to determining whether this is a Devuan or Debian or PEBCAK problem.
--Mike
On Saturday 14 July 2018 21:16:45 Mike Bird wrote:
On Sat July 14 2018 20:38:56 William Morder wrote:
Sorry, got to add my 2 cents' worth here. I believe that this must be a Devuan bug; there could be problems with slim and tdm-trinity, although I think it is immaterial to my point here.
The reason I would trace it to Devuan is that I only ever ran apt-get dist-upgrade; I never tried to install slim or xfce, nor libreoffice, etc., but these were installed automatically. I had assumed, wrongly, that I would get only upgrades of what was already installed.
To upgrade existing packages use "apt-get update && apt-get upgrade".
I always do that, except that I don't put the two commands together. Is there some reason that it is better to run "apt-get update && apt-get upgrade" and not "apt-get update" and then afterwards "apt-get upgrade"?
"apt-get dist-upgrade" is only required in complex situations, e.g. where other packages must be added or removed to accommodate package upgrades. This normally only happens when upgrading to a new release.
Whenever "apt-get dist-upgrade" is needed it is important to carefully check what apt-get proposes to do and determine to your own satisfaction that the proposed actions are sensible, safe, and appropriate.
Yes, I ought to have checked the list carefully, but I wasn't expecting any changes, as I had done this same thing many times previously without incident. I will blame it on my messed-up sleep patterns, and try to be more careful in future.
The information from "apt-get rdepends ..." and/or "aptitude why ..." is the first step on the road to determining whether this is a Devuan or Debian or PEBCAK problem.
--Mike
I'll keep all this in mind when I try to get rid of systemd. Thanks for the information.
Bill
On Sat July 14 2018 23:36:30 William Morder wrote:
On Saturday 14 July 2018 21:16:45 Mike Bird wrote:
To upgrade existing packages use "apt-get update && apt-get upgrade".
I always do that, except that I don't put the two commands together. Is there some reason that it is better to run "apt-get update && apt-get upgrade" and not "apt-get update" and then afterwards "apt-get upgrade"?
The "&&" is an instruction to computers and a reminder to humans not to do the upgrade if the update fails.
--Mike
On Sunday 15 July 2018 00:34:41 Mike Bird wrote:
On Sat July 14 2018 23:36:30 William Morder wrote:
On Saturday 14 July 2018 21:16:45 Mike Bird wrote:
To upgrade existing packages use "apt-get update && apt-get upgrade".
I always do that, except that I don't put the two commands together. Is there some reason that it is better to run "apt-get update && apt-get upgrade" and not "apt-get update" and then afterwards "apt-get upgrade"?
The "&&" is an instruction to computers and a reminder to humans not to do the upgrade if the update fails.
--Mike
Oh, right. Is that like when I couldn't access Trinity's repositories (for some reason, long time ago), and suddenly apt wanted to uninstall everything TDE?
I've seen the && part of the command before, but mostly for getting keyrings, etc., and I prefer to do stuff one step at a time, if possible, to watch what's happening. However, I can (maybe) change.
Bill
On Sat July 14 2018 14:38:56 Stefan Krusche wrote:
(Manually) changed /etc/X11/default-display-manager back to tdm-trinity
This broke your installation and invalidated subsequent tests as /etc/X11/default-display-manager no longer matches the value in /var/cache/debconf/config.dat
dpkg-reconfigure is the way to go.
--Mike
On Sat, 14 Jul 2018 21:09:41 -0700 Mike Bird mgb-trinity@yosemite.net wrote:
(Manually) changed /etc/X11/default-display-manager back to tdm-trinity
This broke your installation and invalidated subsequent tests as /etc/X11/default-display-manager no longer matches the value in /var/cache/debconf/config.dat
dpkg-reconfigure is the way to go.
No this is irrelevant. tdm-trinity and slim install scripts do not check this on install, only if debconf question about display manager was answered.
Quoting Stefan Krusche linux@stefan-krusche.de:
I'm using trinity 14.0.5 from preliminary stable builds on devuan ascii (debian stretch).
Through the most recent upgrade, that I executed on 2018-07-02 11:42:01, tdm (amongst a couple others) got upgraded:
tdm-trinity:amd64 (4:14.0.5~pre39-0debian9.0.0+6, 4:14.0.5~pre42-0debi an9.0.0+6)
After this upgrade tdm wouldn't start anymore and in /var/log/boot I found this error message:
Not starting Trinity Display Manager (tdm); it is not the default display manager.
The file is there: $ ls -l /etc/X11/default-display-manager -rw-r--r-- 1 root root 14 Jul 2 11:42 /etc/X11/default-display-manager
And it says: $ cat /etc/X11/default-display-manager /usr/bin/slim
Solution:
$ dpkg-reconfigure tdm-trinity
Of course, tdm was the default display manager already before the upgrade, and, as you can guess from the above, slim is installed, too.
I think, it should not be necessary to reconfigure the display manager, or, least, the user should be prompted to do so at installation.
IIRC, this happened already at the previous upgrade to ~pre39.
Has anybody seen this? Do you think it is a bug?
FWIW, I've seen this a time or two in Trinity 3.5.13 -- PSB.
Jonesy
-
deloptes -
J Leslie Turriff -
Jimmy Johnson -
Mike Bird -
Nick Koretsky -
Stefan Krusche -
The Joneses -
Thierry de Coulon -
William Morder