20 Dec
2019
20 Dec
'19
11:52 p.m.
Hello TDE users/developers:
First, let me take this opportunity to state, once again, TDE is by far,
my favorite desktop. I have used it for many years, and continue to
support it financially and encourage all users to do likewise.
I am using debian/buster now since it's release. I am also using the
"preliminary stable builds" of TDE using the following location:
deb http://mirror.ppa.trinitydesktop.org/trinity-sb buster deps-r14 main-r14
I am having 2 problems. The first is with TDM, which I will describe
here. I will ask for help on the 2nd problem later.
In addition to tdm-trinity, I also have 2 other login managers
installed: lightdm and lxdm. Both of these are working fine. Only TDM
has this problem. I would much prefer to use TDM.
If I boot up under TDM (after running dpkg-reconfigure tdm-trinity first
to initiate TDM into the boot sequence), it starts fine, but
continuously hangs in the main console with one of the infamous systemd
problems wherein we get the "a startjob is running ..." and it NEVER
ends until rebooted. The TDM session appears to run fine, and I can
login and run TDE fine. However, because the vt1 console is never
ending waiting to complete, I have no other VT consoles. Essentially, I
have NO virtual consoles at all. Further, computer resources are always
wasted and never ends waiting for the the startup to completely finish.
This ONLY happens when booting up with TDM.
I can bootup with LXDM or LIGHTDM and this does not happen. Further, I
can issue a "systemctl stop lightdm" or "systemctl stop lxdm"
(depending
on which is running from the boot), then issue a "systemctl start
tdm-trinity" and TDM runs fine and there is not a never ending startjob
waiting to complete. So, it appears that TDM does not start in the same
order of the boot sequence as LXDM and/or LIGHTDM which is causing this
problem.
It is at this point, where I need some help in how to fix it, and I
suspect that all debian/buster users may have the same issue, but not
sure of course. I hope I can help get his bug fixed before the final
release of TDE for buster.
Thanks again.
Jim Freels, PhD (retired)
21 Dec
21 Dec
7:37 a.m.
New subject: [trinity-users] trouble with tdm on debian/buster
On Saturday 21 December 2019 00.52:35 James D Freels wrote:
(...)
If I boot up under TDM (after running dpkg-reconfigure tdm-trinity first
to initiate TDM into the boot sequence), it starts fine, but
continuously hangs in the main console with one of the infamous systemd
problems wherein we get the "a startjob is running ..." and it NEVER
ends until rebooted.
(...)
Essentially, I
have NO virtual consoles at all.
(...)
It is at this point, where I need some help in how to
fix it, and I
suspect that all debian/buster users may have the same issue, but not
sure of course.
Hello,
I am running Buster with the preliminary builds too and I am not having this
issue. I have set the timout to 5s however.
What is the startjob that hangs?
Thierry
8 a.m.
New subject: [trinity-users] trouble with tdm on debian/buster
Anno domini 2019 Sat, 21 Dec 08:37:32 +0100
Thierry de Coulon scripsit:
On Saturday 21 December 2019 00.52:35 James D Freels
wrote:
(...)
May not be of much use (Devuan here) but RND takes an eternity to create entropy and
blocks anthing with network written on it (ssh, ...). "haveged" lightens the
burden a bit (takes ~ 1 minute to start), but I had to modify the sysv scripts to send all
offending processes to the background. Now I'm back to 15 sec. boottime.
If I boot up under TDM (after running dpkg-reconfigure tdm-trinity first
to initiate TDM into the boot sequence), it starts fine, but
continuously hangs in the main console with one of the infamous systemd
problems wherein we get the "a startjob is running ..." and it NEVER
ends until rebooted.
(...)
Essentially, I
have NO virtual consoles at all.
(...)
It is at this point, where I need some help in
how to fix it, and I
suspect that all debian/buster users may have the same issue, but not
sure of course.
Hello,
I am running Buster with the preliminary builds too and I am not having this
issue. I have set the timout to 5s however.
What is the startjob that hangs?
Thierry
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-users-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-users-help(a)lists.pearsoncomputing.net
Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
--
Please do not email me anything that you are not comfortable also sharing with the NSA,
CIA ...
5:14 p.m.
New subject: [trinity-users] trouble with tdm on debian/buster
I could certainly try this if you give me the specifics of how you did
it. Thanks for the feedback.
On 12/21/19 3:00 AM, Dr. Nikolaus Klepp wrote:
Anno domini 2019 Sat, 21 Dec 08:37:32 +0100
Thierry de Coulon scripsit:
On Saturday 21 December 2019 00.52:35 James D
Freels wrote:
(...)
May not be of much use (Devuan here) but RND
takes an eternity to create entropy and blocks anthing with network written on it (ssh,
...). "haveged" lightens the burden a bit (takes ~ 1 minute to start), but I had
to modify the sysv scripts to send all offending processes to the background. Now I'm
back to 15 sec. boottime.
If I boot up under TDM (after running
dpkg-reconfigure tdm-trinity first
to initiate TDM into the boot sequence), it starts fine, but
continuously hangs in the main console with one of the infamous systemd
problems wherein we get the "a startjob is running ..." and it NEVER
ends until rebooted.
(...)
Essentially, I
have NO virtual consoles at all.
(...)
It is at this point, where I need some help in
how to fix it, and I
suspect that all debian/buster users may have the same issue, but not
sure of course.
Hello,
I am running Buster with the preliminary builds too and I am not having this
issue. I have set the timout to 5s however.
What is the startjob that hangs? Thierry
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-users-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-users-help(a)lists.pearsoncomputing.net
Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
5:18 p.m.
New subject: [trinity-users] trouble with tdm on debian/buster
Anno domini 2019 Sat, 21 Dec 12:14:33 -0500
James D Freels scripsit:
I could certainly try this if you give me the
specifics of how you did
it. Thanks for the feedback
#apt-get install haveged
... might be sufficient. The rest of my post contains info on how to get it done on sysv -
don't know how to do it on systemd.
Nik
On 12/21/19 3:00 AM, Dr. Nikolaus Klepp wrote:
--
Please do not email me anything that you are not comfortable also sharing with the NSA,
CIA ...
Anno domini 2019 Sat, 21 Dec 08:37:32 +0100
Thierry de Coulon scripsit:
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-users-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-users-help(a)lists.pearsoncomputing.net
Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Saturday 21 December 2019 00.52:35 James D
Freels wrote:
(...)
May not be of much use (Devuan here) but RND
takes an eternity to create entropy and blocks anthing with network written on it (ssh,
...). "haveged" lightens the burden a bit (takes ~ 1 minute to start), but I had
to modify the sysv scripts to send all offending processes to the background. Now I'm
back to 15 sec. boottime.
If I boot up under TDM (after running
dpkg-reconfigure tdm-trinity first
to initiate TDM into the boot sequence), it starts fine, but
continuously hangs in the main console with one of the infamous systemd
problems wherein we get the "a startjob is running ..." and it NEVER
ends until rebooted.
(...)
Essentially, I
have NO virtual consoles at all.
(...)
It is at this point, where I need some help in
how to fix it, and I
suspect that all debian/buster users may have the same issue, but not
sure of course.
Hello,
I am running Buster with the preliminary builds too and I am not having this
issue. I have set the timout to 5s however.
What is the startjob that hangs? Thierry
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-users-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-users-help(a)lists.pearsoncomputing.net
Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
5:33 p.m.
New subject: [trinity-users] trouble with tdm on debian/buster
Turns out I already have haveged installed. I must have tried this in
my previous attempt to fix this problem by systemd hacking.
On 12/21/19 12:18 PM, Nikolaus Klepp wrote:
#apt-get install haveged
... might be sufficient. The rest of my post contains info on how to get it done on sysv
- don't know how to do it on systemd.
Nik
5:51 p.m.
New subject: [trinity-users] trouble with tdm on debian/buster
On Saturday 21 December 2019 09:18:53 Nikolaus Klepp wrote:
Anno domini 2019 Sat, 21 Dec 12:14:33 -0500
James D Freels scripsit:
Most who have had problems with the system hanging would seem to blame it on
systemd, and have switched from Debian to Devuan. If your hardware is old,
and your resources limited, this might be a good choice. I have had no system
hangups whatsoever since making the move to Devuan.
However, it may not be everybody's way; and what really matters, for the
actual user, is what works, because we have other things to do besides
wrestling with our machines to get them to behave.
Michele Calgaro gave a solution that works for her; look under these headings:
"Re: [trinity-users] Has systemd broken Debian this time?" (15 July 2019)
"Re: [trinity-users] Systemd" (27 July 2019).
I quote her solution from the latter email:
****
You can uncomment the line with DefaultTimeoutStartSec and
DefaultTimeoutStopSec in /etc/systemd/system.conf
DefaultTimeoutStartSec=5s
DefaultTimeoutStopSec=5s
Works like a charm.
Cheers
Michele
****
I hope this may be of some help. This assumes, of course, that the problem may
be with systemd, and not with tdm.
Bill
I could certainly try this if you give me the
specifics of how you did
it. Thanks for the feedback
#apt-get install haveged
... might be sufficient. The rest of my post contains info on how to get it
done on sysv - don't know how to do it on systemd.
Nik
> On 12/21/19 3:00 AM, Dr. Nikolaus Klepp wrote:
> > Anno domini 2019 Sat, 21 Dec 08:37:32 +0100
> >
> > Thierry de Coulon scripsit:
> >> On Saturday 21 December 2019 00.52:35 James D Freels wrote:
> >> (...)
> >>
> >>> If I boot up under TDM (after running dpkg-reconfigure tdm-trinity
> >>> first to initiate TDM into the boot sequence), it starts fine, but
> >>> continuously hangs in the main console with one of the infamous
> >>> systemd problems wherein we get the "a startjob is running
..." and
> >>> it NEVER ends until rebooted.
> >>
> >> (...)
> >>
> >>> Essentially, I
> >>> have NO virtual consoles at all.
> >>
> >> (...)
> >>
> >>> It is at this point, where I need some help in how to fix it, and I
> >>> suspect that all debian/buster users may have the same issue, but not
> >>> sure of course.
> >>
> >> Hello,
> >>
> >> I am running Buster with the preliminary builds too and I am not
> >> having this issue. I have set the timout to 5s however.
> >>
> >> What is the startjob that hangs?
> >
> > May not be of much use (Devuan here) but RND takes an eternity to
> > create entropy and blocks anthing with network written on it (ssh,
> > ...). "haveged" lightens the burden a bit (takes ~ 1 minute to
start),
> > but I had to modify the sysv scripts to send all offending processes to
> > the background. Now I'm back to 15 sec. boottime.
> >
> >> Thierry
> >>
5:33 p.m.
New subject: [trinity-users] trouble with tdm on debian/buster
On Saturday 21 December 2019 18.14:33 James D Freels wrote:
I could certainly try this if you give me the
specifics of how you did
it. Thanks for the feedback.
in /etc/systemd/system.conf:
(...)
#DefaultStandardOutput=journal
#DefaultStandardError=inherit
DefaultTimeoutStartSec=5s
DefaultTimeoutStopSec=5s
#DefaultRestartSec=100ms
#DefaultStartLimitIntervalSec=10s
(...)
Thierry
5:13 p.m.
New subject: [trinity-users] trouble with tdm on debian/buster
The startjob that hangs is "Hold".
A start job is running for Hold unt… finishes up (7min 23s / no limit)
I have tried setting the timout to a low number to address this issue,
but it does not seem to fix this problem. Perhaps I did not set it in
the right way/place.
On 12/21/19 2:37 AM, Thierry de Coulon wrote:
On Saturday 21 December 2019 00.52:35 James D Freels
wrote:
(...)
If I boot up under TDM (after running
dpkg-reconfigure tdm-trinity first
to initiate TDM into the boot sequence), it starts fine, but
continuously hangs in the main console with one of the infamous systemd
problems wherein we get the "a startjob is running ..." and it NEVER
ends until rebooted.
(...)
Essentially, I
have NO virtual consoles at all.
(...)
It is at this point, where I need some help in
how to fix it, and I
suspect that all debian/buster users may have the same issue, but not
sure of course.
Hello,
I am running Buster with the preliminary builds too and I am not having this
issue. I have set the timout to 5s however.
What is the startjob that hangs?
Thierry
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-users-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-users-help(a)lists.pearsoncomputing.net
Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
8:02 a.m.
New subject: [trinity-users] trouble with tdm on debian/buster
On Fri, 20 Dec 2019 18:52:35 -0500
James D Freels <freelsjd(a)gmail.com> wrote:
If I boot up under TDM (after running dpkg-reconfigure tdm-trinity first
to initiate TDM into the boot sequence), it starts fine, but
continuously hangs in the main console with one of the infamous systemd
problems wherein we get the "a startjob is running ..." and it NEVER
ends until rebooted. The TDM session appears to run fine, and I can
login and run TDE fine. However, because the vt1 console is never
ending waiting to complete, I have no other VT consoles. Essentially, I
have NO virtual consoles at all. Further, computer resources are always
wasted and never ends waiting for the the startup to completely finish.
This ONLY happens when booting up with TDM.
I can bootup with LXDM or LIGHTDM and this does not happen. Further, I
can issue a "systemctl stop lightdm" or "systemctl stop lxdm"
(depending
on which is running from the boot), then issue a "systemctl start
tdm-trinity" and TDM runs fine and there is not a never ending startjob
waiting to complete. So, it appears that TDM does not start in the same
order of the boot sequence as LXDM and/or LIGHTDM which is causing this
problem.
It is at this point, where I need some help in how to fix it, and I
suspect that all debian/buster users may have the same issue, but not
sure of course. I hope I can help get his bug fixed before the final
release of TDE for buster.
I dont think its a bug in TDE, this looks like some systemd problem, so a
steps to deal with systemd problems has to be followed.
Starting with 'systemd-analyze blame' and 'systemd-analyze
critical-chain'.
--
Nick Koretsky (nick.koretsky(a)gmail.com)
5:18 p.m.
New subject: [trinity-users] trouble with tdm on debian/buster
This is a great suggestion. I will give it a try and report back later.
On 12/21/19 3:02 AM, Nick Koretsky wrote:
On Fri, 20 Dec 2019 18:52:35 -0500
James D Freels <freelsjd(a)gmail.com> wrote:
If I boot up under TDM (after running
dpkg-reconfigure tdm-trinity first
to initiate TDM into the boot sequence), it starts fine, but
continuously hangs in the main console with one of the infamous systemd
problems wherein we get the "a startjob is running ..." and it NEVER
ends until rebooted. The TDM session appears to run fine, and I can
login and run TDE fine. However, because the vt1 console is never
ending waiting to complete, I have no other VT consoles. Essentially, I
have NO virtual consoles at all. Further, computer resources are always
wasted and never ends waiting for the the startup to completely finish.
This ONLY happens when booting up with TDM.
I can bootup with LXDM or LIGHTDM and this does not happen. Further, I
can issue a "systemctl stop lightdm" or "systemctl stop lxdm"
(depending
on which is running from the boot), then issue a "systemctl start
tdm-trinity" and TDM runs fine and there is not a never ending startjob
waiting to complete. So, it appears that TDM does not start in the same
order of the boot sequence as LXDM and/or LIGHTDM which is causing this
problem.
It is at this point, where I need some help in how to fix it, and I
suspect that all debian/buster users may have the same issue, but not
sure of course. I hope I can help get his bug fixed before the final
release of TDE for buster.
I dont think its a bug in TDE, this looks like some systemd problem, so a
steps to deal with systemd problems has to be followed.
Starting with 'systemd-analyze blame' and 'systemd-analyze
critical-chain'.
5:30 p.m.
New subject: [trinity-users] trouble with tdm on debian/buster
OK. Had to reboot with TDM active to uncover this issue.
When I issue systemd-analyze blame , I get:
systemd-analyze blame
Bootup is not yet finished
(org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0).
Please try again later.
Hint: Use 'systemctl list-jobs' to see active jobs
Of course later never comes since this step continuously hangs. So
taking the suggestion, the output from systemctl list-jobs is:
JOB UNIT TYPE STATE
147 getty(a)tty1.service start waiting
2 multi-user.target start waiting
1 graphical.target start waiting
129 systemd-update-utmp-runlevel.service start waiting
105 plymouth-quit-wait.service start running
146 getty.target start waiting
6 jobs listed.
So, it appears related to plymouth. Is plymouth used in TDM?
Also tried systemd-analyze critical-chain, and get identical output
Bootup is not yet finished
(org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0).
Please try again later.
Hint: Use 'systemctl list-jobs' to see active jobs
On 12/21/19 12:18 PM, James D Freels wrote:
This is a great suggestion. I will give it a try and
report back later.
On 12/21/19 3:02 AM, Nick Koretsky wrote:
> On Fri, 20 Dec 2019 18:52:35 -0500
> James D Freels <freelsjd(a)gmail.com> wrote:
>
>> If I boot up under TDM (after running dpkg-reconfigure tdm-trinity
>> first
>> to initiate TDM into the boot sequence), it starts fine, but
>> continuously hangs in the main console with one of the infamous systemd
>> problems wherein we get the "a startjob is running ..." and it NEVER
>> ends until rebooted. The TDM session appears to run fine, and I can
>> login and run TDE fine. However, because the vt1 console is never
>> ending waiting to complete, I have no other VT consoles. Essentially, I
>> have NO virtual consoles at all. Further, computer resources are
>> always
>> wasted and never ends waiting for the the startup to completely finish.
>> This ONLY happens when booting up with TDM.
>>
>> I can bootup with LXDM or LIGHTDM and this does not happen. Further, I
>> can issue a "systemctl stop lightdm" or "systemctl stop lxdm"
>> (depending
>> on which is running from the boot), then issue a "systemctl start
>> tdm-trinity" and TDM runs fine and there is not a never ending startjob
>> waiting to complete. So, it appears that TDM does not start in the
>> same
>> order of the boot sequence as LXDM and/or LIGHTDM which is causing this
>> problem.
>>
>> It is at this point, where I need some help in how to fix it, and I
>> suspect that all debian/buster users may have the same issue, but not
>> sure of course. I hope I can help get his bug fixed before the final
>> release of TDE for buster.
>>
> I dont think its a bug in TDE, this looks like some systemd problem,
> so a
> steps to deal with systemd problems has to be followed.
> Starting with 'systemd-analyze blame' and 'systemd-analyze
> critical-chain'.
>
>
5:46 p.m.
New subject: [trinity-users] trouble with tdm on debian/buster
Anno domini 2019 Sat, 21 Dec 12:30:53 -0500
James D Freels scripsit:
OK. Had to reboot with TDM active to uncover this
issue.
When I issue systemd-analyze blame , I get:
systemd-analyze blame
Bootup is not yet finished
(org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0).
Please try again later.
Hint: Use 'systemctl list-jobs' to see active jobs
Of course later never comes since this step continuously hangs. So
taking the suggestion, the output from systemctl list-jobs is:
JOB UNIT TYPE STATE
147 getty(a)tty1.service start waiting
2 multi-user.target start waiting
1 graphical.target start waiting
129 systemd-update-utmp-runlevel.service start waiting
105 plymouth-quit-wait.service start running
146 getty.target start waiting
6 jobs listed.
So, it appears related to plymouth. Is plymouth used in TDM?
You can saferly purge all plymouth* packages. It's just eyecandy and a source of
interestring problems.
Nik
Also tried systemd-analyze critical-chain, and get identical output
Bootup is not yet finished
(org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0).
Please try again later.
Hint: Use 'systemctl list-jobs' to see active jobs
On 12/21/19 12:18 PM, James D Freels wrote:
--
Please do not email me anything that you are not comfortable also sharing with the NSA,
CIA ...
This is a great suggestion. I will give it a try
and report back later.
On 12/21/19 3:02 AM, Nick Koretsky wrote:
> On Fri, 20 Dec 2019 18:52:35 -0500
> James D Freels <freelsjd(a)gmail.com> wrote:
>
>> If I boot up under TDM (after running dpkg-reconfigure tdm-trinity
>> first
>> to initiate TDM into the boot sequence), it starts fine, but
>> continuously hangs in the main console with one of the infamous systemd
>> problems wherein we get the "a startjob is running ..." and it NEVER
>> ends until rebooted. The TDM session appears to run fine, and I can
>> login and run TDE fine. However, because the vt1 console is never
>> ending waiting to complete, I have no other VT consoles. Essentially, I
>> have NO virtual consoles at all. Further, computer resources are
>> always
>> wasted and never ends waiting for the the startup to completely finish.
>> This ONLY happens when booting up with TDM.
>>
>> I can bootup with LXDM or LIGHTDM and this does not happen. Further, I
>> can issue a "systemctl stop lightdm" or "systemctl stop lxdm"
>> (depending
>> on which is running from the boot), then issue a "systemctl start
>> tdm-trinity" and TDM runs fine and there is not a never ending startjob
>> waiting to complete. So, it appears that TDM does not start in the
>> same
>> order of the boot sequence as LXDM and/or LIGHTDM which is causing this
>> problem.
>>
>> It is at this point, where I need some help in how to fix it, and I
>> suspect that all debian/buster users may have the same issue, but not
>> sure of course. I hope I can help get his bug fixed before the final
>> release of TDE for buster.
>>
> I dont think its a bug in TDE, this looks like some systemd problem,
> so a
> steps to deal with systemd problems has to be followed.
> Starting with 'systemd-analyze blame' and 'systemd-analyze
> critical-chain'.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-users-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-users-help(a)lists.pearsoncomputing.net
Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
6:26 p.m.
New subject: [trinity-users] trouble with tdm on debian/buster
This fixed the problem. I think I recall plymouth is needed for kde>3.5 ?
Also, I tried the faster DefaultTimeout times, and that was not the
issue here.
Still not sure if this is a bug, but it certainly appears that if
plymouth is in the system, it will cause tdm to behave like this ?
On 12/21/19 12:46 PM, Dr. Nikolaus Klepp wrote:
You can saferly purge all plymouth* packages. It's
just eyecandy and a source of interestring problems.
Nik
6:33 p.m.
New subject: [trinity-users] trouble with tdm on debian/buster
James D Freels composed on 2019-12-21 13:26 (UTC-0500):
This fixed the problem. I think I recall plymouth is
needed for kde>3.5 ?
IME, Plymouth is never needed except if running TDE on Mageia, where it's required
only because of Mageia's own broken mandatory theming dependencies.
--
Evolution as taught in public schools is religion, not science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
5:35 p.m.
New subject: [trinity-users] trouble with tdm on debian/buster
I don't know if it is a TDM bug or not. I DO know that if I boot with
lightdm or lxdm and NOT tdm, then this problem does not occur.
My guess is that perhaps tdm is starting at a different "level" then
lxdm or lightdm, and causes a conflict of some kind with something else?
On 12/21/19 3:02 AM, Nick Koretsky wrote:
I dont think its a bug in TDE, this looks like some
systemd problem, so a
steps to deal with systemd problems has to be followed.
Starting with 'systemd-analyze blame' and 'systemd-analyze
critical-chain'.
9:33 p.m.
James D Freels wrote:
It is at this point, where I need some help in how to
fix it, and I
suspect that all debian/buster users may have the same issue, but not
sure of course. I hope I can help get his bug fixed before the final
release of TDE for buster.
Thanks again.
Jim Freels, PhD (retired)
I am amazed that no one suggested following:
There is a known bug related to systemd in /lib/systemd/system/tdm.service
Just comment out the Conflicts line
$ cat /lib/systemd/system/tdm.service
[Unit]
Description=Trinity Display Manager
Documentation=man:tdm-trinity(1)
#Conflicts=getty(a)tty7.service plymouth-quit.service
After=systemd-user-sessions.service getty(a)tty7.service plymouth-quit.service
[Service]
# temporary safety check until all DMs are converted to correct
# display-manager.service symlink handling
ExecStartPre=/bin/sh -c '[ "$(basename
$(cat /etc/X11/default-display-manager 2>/dev/null))" = "tdm" ]'
ExecStart=/opt/trinity/bin/tdm
Restart=always
regards
11:40 p.m.
New subject: [trinity-users] Re: trouble with tdm on debian/buster
On Sat, 21 Dec 2019 22:33:22 +0100
deloptes <deloptes(a)gmail.com> wrote:
James D Freels wrote:
This a hacky solution that can theoretically led to problems
(afaik depending on video drivers used plymouth could prevent Xorg from
starting). The source of the problem here is that tdm doesn't correctly
signal to plymouth to quit. So correct action is to disable/uninstall
plymouth, not to edit tdm.service
--
Nick Koretsky (nick.koretsky(a)gmail.com)
It is at this point, where I need some help in
how to fix it, and I
suspect that all debian/buster users may have the same issue, but not
sure of course. I hope I can help get his bug fixed before the final
release of TDE for buster.
Thanks again.
Jim Freels, PhD (retired)
I am amazed that no one suggested following:
There is a known bug related to systemd in /lib/systemd/system/tdm.service
Just comment out the Conflicts line
$ cat /lib/systemd/system/tdm.service
[Unit]
Description=Trinity Display Manager
Documentation=man:tdm-trinity(1)
#Conflicts=getty(a)tty7.service plymouth-quit.service
After=systemd-user-sessions.service getty(a)tty7.service
plymouth-quit.service
[Service]
# temporary safety check until all DMs are converted to correct
# display-manager.service symlink handling
ExecStartPre=/bin/sh -c '[ "$(basename
$(cat /etc/X11/default-display-manager 2>/dev/null))" = "tdm" ]'
ExecStart=/opt/trinity/bin/tdm
Restart=always
22 Dec
22 Dec
12:12 a.m.
Nick Koretsky wrote:
This a hacky solution that can theoretically led to
problems
(afaik depending on video drivers used plymouth could prevent Xorg from
starting). The source of the problem here is that tdm doesn't correctly
signal to plymouth to quit. So correct action is to disable/uninstall
plymouth, not to edit tdm.service
Interesting - what should tdm do to signal to plymouth to quit? I don't want
to uninstall it.
12:20 a.m.
Nick Koretsky wrote:
This a hacky solution that can theoretically led to
problems
(afaik depending on video drivers used plymouth could prevent Xorg from
starting). The source of the problem here is that tdm doesn't correctly
signal to plymouth to quit. So correct action is to disable/uninstall
plymouth, not to edit tdm.service
Also why after commenting out this line tdm starts and plymouth is not
running anymore?
12:38 a.m.
New subject: [trinity-users] Re: Re: trouble with tdm on debian/buster
deloptes composed on 2019-12-22 01:20 (UTC+0100):
Also why after commenting out this line tdm starts and
plymouth is not
running anymore?
The After line still applies.
--
Evolution as taught in public schools is religion, not science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
5:10 p.m.
Well, this has turned out to be a rather fruitful discussion. My
attitude about TDE is a bit like the history of TeX. If you recall
Knuth made a long-standing offer to pay people to find errors in his
software and he would pay them if he agreed that it was a bug, and it
got fixed. He did not add many new features, but instead, concentrated
on getting all the errors out. As a result, TeX has not changed in
feature set, but is still used by many people worldwide as one of the
most error-free and powerful typesetting tools available.
I am not suggested any monetary reward, but I do think that one of the
benefits of TDE may be that eventually it could become error-free. Many
bugs, like this one, are caused by software interfaces outside TDE, and
I suspect this will go on forever. But, internally, we have a chance to
have an error-free desktop for Linux that could live for the ages. I do
think TDE is becoming more popular now than ever, perhaps for that reason.
I will sign off now that we think we have gotten this "bug" at least
defined. I will leave it to the experts to decide how best to fix it
for the ages.
Thank you to all for your help and wisdom.
Merry Christmas.
On 12/20/19 6:52 PM, James D Freels wrote:
Hello TDE users/developers:
First, let me take this opportunity to state, once again, TDE is by
far, my favorite desktop. I have used it for many years, and continue
to support it financially and encourage all users to do likewise.
I am using debian/buster now since it's release. I am also using the
"preliminary stable builds" of TDE using the following location:
deb http://mirror.ppa.trinitydesktop.org/trinity-sb buster deps-r14
main-r14
I am having 2 problems. The first is with TDM, which I will describe
here. I will ask for help on the 2nd problem later.
In addition to tdm-trinity, I also have 2 other login managers
installed: lightdm and lxdm. Both of these are working fine. Only TDM
has this problem. I would much prefer to use TDM.
If I boot up under TDM (after running dpkg-reconfigure tdm-trinity
first to initiate TDM into the boot sequence), it starts fine, but
continuously hangs in the main console with one of the infamous
systemd problems wherein we get the "a startjob is running ..." and it
NEVER ends until rebooted. The TDM session appears to run fine, and I
can login and run TDE fine. However, because the vt1 console is never
ending waiting to complete, I have no other VT consoles. Essentially,
I have NO virtual consoles at all. Further, computer resources are
always wasted and never ends waiting for the the startup to completely
finish. This ONLY happens when booting up with TDM.
I can bootup with LXDM or LIGHTDM and this does not happen. Further, I
can issue a "systemctl stop lightdm" or "systemctl stop lxdm"
(depending on which is running from the boot), then issue a "systemctl
start tdm-trinity" and TDM runs fine and there is not a never ending
startjob waiting to complete. So, it appears that TDM does not start
in the same order of the boot sequence as LXDM and/or LIGHTDM which is
causing this problem.
It is at this point, where I need some help in how to fix it, and I
suspect that all debian/buster users may have the same issue, but not
sure of course. I hope I can help get his bug fixed before the final
release of TDE for buster.
Thanks again.
Jim Freels, PhD (retired)
--
James D. Freels, Ph.D., P.E.
freelsjd(a)gmail.com
865-457-6742 (landline)
865-919-0320 (cell)
1827
days inactive
1829
days old
22 comments
8 participants
participants (8)
-
deloptes -
Dr. Nikolaus Klepp -
Felix Miata -
James D Freels -
Nick Koretsky -
Nikolaus Klepp
-
Thierry de Coulon -
William Morder via trinity-users