Bug 1233

Strange, on my test machine I have not noticed anything like that. I'll try to reinstall all packages Trinity, to be sure, I have versions from PPA (and not from my own builds). And then I'll try it again.

All packages I downloaded again, reinstalled and the problem I am unable to reproduce. Restarts are working properly. Kernel I tried both - from backports and also from distribution (Squeeze). Platform amd64.

It's strange to me how KDM should trigger a prompt to the password for maintenance?

Is this report a duplicate of report 1209?

It seems that these bugs have something in common. But Kristopher no mention prompt for maintenance mode. We need more information.

My experiences with the solutions proposed in the bug 1209 and tested with different variants in "Control Center > System Admin > Login Manager > Shutdown":

* Restart
Original: /sbin/reboot
Result: "Give root password for maintenance (or type Control-D to continue)"
If press Ctrl-D: "INIT: no more processes left in this runlevel" (thus remains)

Change to: /sbin/shutdown -r now
Result (like the original): "Give root password for maintenance (or type Control-D to continue)"
If press Ctrl-D: "INIT: no more processes left in this runlevel" (thus remains)

Change to: /sbin/shutdown -f now
Result: "modem-manager: Caught signal 15, shutting down" (thus remains)

Change to: /sbin/shutdown -fr now
Result (like the original): "Give root password for maintenance (or type Control-D to continue)"
If press Ctrl-D: "INIT: no more processes left in this runlevel" (thus remains)

Change to: /sbin/shutdown -r -g0
Result (like the original): "Give root password for maintenance (or type Control-D to continue)"

In Ctrl+Alt+F1 terminal: /sbin/reboot -i
Result: Reboot instantly (not shutdown?)
(In KControl - KDM module don't work: "Give root password for maintenance (or type Control-D to continue)")

In Ctrl+Alt+F1 terminal: /sbin/shutdown now && reboot -i
Result: Reboot instantly (not shutdown?)
(In KControl - KDM module: appears a real terminal ask for login, the "&&" seems don't work in KDM)

In Ctrl+Alt+F1 terminal: /sbin/shutdown -f -i0 now &&  /sbin/shutdown -f -i6 now
Result: Reboot well (with INIT:...)
In KControl - KDM module: appears a real terminal ask for login
I make a new text file named "/sbin/reinicia" with the content "/sbin/shutdown -f -i0 now && /sbin/shutdown -f -i6 now" (without quotes, of course), and in "Control Center > System Admin > Login Manager > Shutdown" in the Restart I choose /sbin/reinicia. The system reboot well.

* Turn-off

* Restart
Original: /sbin/halt
Result: "INIT: no more processes left in this runlevel" (thus remains)

Change to: /sbin/shutdown -hP now
Result (like the original): "INIT: no more processes left in this runlevel" (thus remains)

Change to: /sbin/shutdown -P now
Result: Appears a real terminal ask for login

Change to: /sbin/shutdown -h now
Result (like the original): "INIT: no more processes left in this runlevel" (thus remains)

Change to: /sbin/shutdown -h -i6 now
Result (like the original): "INIT: no more processes left in this runlevel" (thus remains)

Change to: /sbin/shutdown -hP -i6 now
Result: Appears a real terminal ask for login

I make a new text file named "/sbin/apaga" with the content "/sbin/shutdown -hP -i0 now && /sbin/shutdown -hP -i6 now" (without quotes, of course), and in "Control Center > System Admin > Login Manager > Shutdown" in the TurnOff I choose /sbin/apaga. The system shutdown don't work: "INIT: no more processes left in this runlevel"

Change content "/sbin/apaga" to "/sbin/shutdown -h -i0 now && /sbin/shutdown -h -i6 now" the system _restart_ well.

Change content "/sbin/apaga" to "/sbin/shutdown -P -i0 now && /sbin/shutdown -P -i6 now": the error is "modem-manager: Caught signal 15, shutting down" (thus remains)

Change content "/sbin/apaga" to "/sbin/shutdown -h -i0 now && /sbin/shutdown -h -i6 now && /sbin/shutdown -P now" the system _restart_ well.

Change content "/sbin/apaga" to "/sbin/shutdown now && /sbin/halt" 
Result (like the original): "INIT: no more processes left in this runlevel" (thus remains)

Change content "/sbin/apaga" to "/sbin/shutdown -i0 now && /sbin/shutdown -i6 now && /sbin/poweroff" the system poweroff well

I'm also experiencing this.

The remedies in #1209 don't work for me either.

Alexi's shutdown doesn't work for me.  As far as I can see it starts a reboot & then tries to power-off in the reboot.  It's probably a matter of timing whether this works or not on any particular system.

In his reboot sequence "/sbin/shutdown -h -i0 now && /sbin/shutdown -h-i6 now && /sbin/shutdown -P now" the last term is a no-op.  The -P should have a -h with it.   As it stands this invocation of shutdown throws an error & is ignored so it can be left off, it's the -i6 which causes the reboot.

gdm works without problems so if you have a dual Gnome/Trinity install you can use that as a work-around.

I did some investigation putting echoes into the various scripts in /etc/rc0.d and it seems that things go astray in sendsigs.  The command killall5 -15 $OMITPIDS # SIGTERM doesn't seem to return; I get no response to any echo after this with kdm but I do with gdm.

Please can you test if will help to turn off SAK?
As is noted in bug 1275.

How to test? Please provide some steps to duplicate. (I'm not a regular TDM user.)

Darrell, thank you for your interest. But as far as I know, this problem has been reported specifically for Debian Squeeze. Moreover, it observes only a few users - to me it has never been reproduced.

Oh, okay. I don't mind testing. Let me know if you change your mind. :)

*** Bug 1209 has been marked as a duplicate of this bug. ***

(In reply to comment #4)
> It seems that these bugs have something in common. But Kristopher no mention
> prompt for maintenance mode. We need more information.

I did not receive a password prompt, neither on reboot nor shutdown. It simply went through the usual shutdown process, then stopped with the "no more processes" error. I was using the Backports kernel when this happened, I do not have the stock kernel from Squeeze. Currently downgrading to 3.5.13.* isn't an option for me personally until I am able to give that machine a hard disk.

I would like to mention the solution from my bug report, which is to visit the TDM settings in Control Center and set the Halt and Reboot commands to "shutdown -hP now" and "shutdown -r now", respectively.

This issue does not appear on Arch Linux under 3.5.13.1.

(In reply to comment #7)
> Please can you test if will help to turn off SAK?
> As is noted in bug 1275.

I've already taken care of that -- I turned off SAK many many months ago when I found out this was possible. It does not resolve the issue.

Are you sure this is a TDE-specific problem?

TDM should simply be calling /sbin/poweroff or /sbin/reboot depending on the user's request.  If either of those commands fail to work properly, that would be a distribution-specific problem in Debian.

Note that I have seen at least one Ubuntu system fail to shutdown, regardless of whether TDM was running, after its hard disk had been corrupted.  In that particularly irritating case simply upgrading to the next version of Ubuntu fixed the shutdown issue.

If you switch to a virtual terminal and issue /sbin/poweroff or /sbin/reboot, does your system power off normally or reboot normally?

(In reply to comment #14)
> Are you sure this is a TDE-specific problem?

Yes, I do not experience this elsewhere.

<snip>
> If you switch to a virtual terminal and issue /sbin/poweroff or /sbin/reboot,
> does your system power off normally or reboot normally?

If TDM has already been started since bootup (regardless of whether or not it's actually running), then no, it does not shut down normally. I still experience this bug.

If, however, TDM has *not* been run since bootup, /sbin/poweroff and /sbin/reboot work exactly as they should (as in, they will poweroff or reboot my machine, respectively).

In essence, whether /sbin/poweroff and /sbin/reboot work correctly seems directly dependent on whether or not TDM has been running. I have already tested this several times before, and I perform regular fsck's regardless of whether or not they are needed so I know this isn't the issue.

Thanks Kris, that is exactly what I wanted to know! :-)

I cannot replicate this with TDM from GIT on Debian Squeeze, which likely means something is different on my system versus your systems.

Do you have a tdmdistrc file in /etc/trinity/tdm?  Does your tdmrc or tdmdistrc file contain references to a kdm PID file?

Does anyone experiencing this issue have the Debian TDE metapackage (kde-trinity) installed?

Try replacing your /etc/init.d/tdm-trinity file (after backing it up!) with this file from GIT:
http://git.trinitydesktop.org/cgit/tde-packaging/tree/debian/squeeze/tdebase/debian/tdm-trinity.init

Does that fix the problem?

Tim, we're on exactly the same - I am on any of my work or test machines also not able to replicate this problem with "INIT: no more processes left in this runlevel" any v3.5.13.x.

Kris, Alexis - at your machines problem occurs regardless of login into TDE session? If it occurs after login / logout into the session, you can check after logout if kdesktop_lock is terminated properly? In some cases I have observed that regardless of successful logout kdesktop_lock remained running and was neccessary to use killall -9 kdesktop_lock to terminate it.

(In reply to comment #17)
<snip> 
> Do you have a tdmdistrc file in /etc/trinity/tdm?  Does your tdmrc or tdmdistrc
> file contain references to a kdm PID file?

There is no /etc/trinity. I was not aware that directory should exist, I have never seen it in any of my frequent visits to /etc, nor have I ever removed it.

> Does anyone experiencing this issue have the Debian TDE metapackage
> (kde-trinity) installed?

No, it depends on lots of kde* packages that have been removed/replaced in the nightlies repo. From "apt-get install kde-trinity":

===================================================
The following packages have unmet dependencies:
 kde-trinity : Depends: kde-core-trinity (>= 5:47) but it is not going to be installed
               Depends: kdeedu-trinity (>= 4:3.5.5) but it is not going to be installed
               Depends: kdegames-trinity (>= 4:3.5.5) but it is not going to be installed
               Depends: kdetoys-trinity (>= 4:3.5.5) but it is not going to be installed
               Depends: kdeaccessibility-trinity (>= 4:3.5.5) but it is not going to be installed
               Depends: kdeaddons-trinity (>= 4:3.5.5) but it is not going to be installed
               Depends: kdeadmin-trinity (>= 4:3.5.5) but it is not going to be installed
               Depends: kdeartwork-trinity (>= 4:3.5.5) but it is not going to be installed
               Depends: kdegraphics-trinity (>= 4:3.5.5) but it is not going to be installed
               Depends: kdemultimedia-trinity (>= 4:3.5.5) but it is not going to be installed
               Depends: kdenetwork-trinity (>= 4:3.5.5) but it is not going to be installed
               Depends: kdepim-trinity (>= 4:3.5.5) but it is not going to be installed
               Depends: kdeutils-trinity (>= 4:3.5.5) but it is not going to be installed
               Depends: kdewebdev-trinity (>= 4:3.5.5) but it is not going to be installed
               Depends: desktop-base-trinity but it is not installable

> Try replacing your /etc/init.d/tdm-trinity file (after backing it up!) with
> this file from GIT:
> http://git.trinitydesktop.org/cgit/tde-packaging/tree/debian/squeeze/tdebase/debian/tdm-trinity.init
===================================================

> Does that fix the problem?

I will have to test later, I am having a major (non-TDE related) issue with another machine, that takes priority because I need that machine to do some work.

(In reply to comment #18)
<snip>
> Kris, Alexis - at your machines problem occurs regardless of login into TDE
> session?

Yes, it ocurrs regardless.

>If it occurs after login / logout into the session, you can check
> after logout if kdesktop_lock is terminated properly? In some cases I have
> observed that regardless of successful logout kdesktop_lock remained running
> and was neccessary to use killall -9 kdesktop_lock to terminate it.

I cannot test at the moment (see above comment).

(Odpověď na komentář #19)
> (In reply to comment #17)
> <snip> 
> > Do you have a tdmdistrc file in /etc/trinity/tdm?  Does your tdmrc or tdmdistrc
> > file contain references to a kdm PID file?
> 
> There is no /etc/trinity. I was not aware that directory should exist, I have
> never seen it in any of my frequent visits to /etc, nor have I ever removed it.
> 

What? How do you have installed Trinity, if you do not have /etc/trinity!?!

On my system, with TDE 3.5.13.x:

$ dpkg -S /etc/trinity
kdebase-data-trinity, kdelibs-data-trinity, kmail-trinity, klipper-trinity, kate-trinity, amarok-common-trinity, libkleopatra1-trinity, ksysguardd-trinity, kdebase-trinity-bin, konqueror-trinity, kdesktop-trinity, kdm-trinity: /etc/trinity

There is no correct way to have installed trinity, and do not have /etc/trinity.

(In reply to comment #21)
> (Odpověď na komentář #19)
> > (In reply to comment #17)
> > <snip> 
> > > Do you have a tdmdistrc file in /etc/trinity/tdm?  Does your tdmrc or tdmdistrc
> > > file contain references to a kdm PID file?
> > 
> > There is no /etc/trinity. I was not aware that directory should exist, I have
> > never seen it in any of my frequent visits to /etc, nor have I ever removed it.
> > 
> 
> What? How do you have installed Trinity, if you do not have /etc/trinity!?!
<snip>

I simply added the nightlies repos to apt, and used Synaptic to install the packages I need (tdebase, tdelibs, and tdepim, among several other individuals packages I find useful, including tdm and kcontrol).

(In reply to comment #22)
> (In reply to comment #21)
> > (Odpověď na komentář #19)
> > > (In reply to comment #17)
> > > <snip> 
> > > > Do you have a tdmdistrc file in /etc/trinity/tdm?  Does your tdmrc or tdmdistrc
> > > > file contain references to a kdm PID file?
> > > 
> > > There is no /etc/trinity. I was not aware that directory should exist, I have
> > > never seen it in any of my frequent visits to /etc, nor have I ever removed it.
> > > 
> > 
> > What? How do you have installed Trinity, if you do not have /etc/trinity!?!
> <snip>
> 
> I simply added the nightlies repos to apt, and used Synaptic to install the
> packages I need (tdebase, tdelibs, and tdepim, among several other individuals
> packages I find useful, including tdm and kcontrol).

I would also like to have that I have never seen /etc/trinity on ANY of the stable versions of TDE, going from 3.5.12 (the first version I've used) to 3.5.13 and 3.5.13.1. Even with the kde-trinity package installed, /etc/trinity wasn't there. If that's an issue, a bug should be filed, though I'm not familiar enough with the inner workings of TDE to feel confident making the bug report. (note: it might be a Debian-specific packaging issue)

A missing /etc/trinity directory would probably explain the problem.  I am tempted to mark this report invalid, but will instead mark it SRUONLY in the off chance something changed in GIT that resolved the problem.

(Odpověď na komentář #23)
> I would also like to have that I have never seen /etc/trinity on ANY of the
> stable versions of TDE, going from 3.5.12 (the first version I've used) to
> 3.5.13 and 3.5.13.1. Even with the kde-trinity package installed, /etc/trinity
> wasn't there. If that's an issue, a bug should be filed, though I'm not
> familiar enough with the inner workings of TDE to feel confident making the bug
> report. (note: it might be a Debian-specific packaging issue)

I also use the Trinity from 3.5.12 and ever since I have /etc/trinity folder on all machines with Trinity. On my machines I use Debian Squeeze, on the test machine I have various Ubuntu versions and everywhere I have a folder /etc/trinity.

As I said before, there is no correct way to have installed Trinity from debian / ubuntu packages, and not having /etc/trinity folder. If you do not have the folder /etc/trinity, your system is broken.

I am also tempted to mark this report invalid :)

(In reply to comment #24)
> A missing /etc/trinity directory would probably explain the problem.  I am
> tempted to mark this report invalid, but will instead mark it SRUONLY in the
> off chance something changed in GIT that resolved the problem.

Unless the nightlies are *not* built directly from git, this is NOT resolved in
git. Remember, I am using the nightlies and I still see this issue.

(In reply to comment #25)
> (Odpověď na komentář #23)
> > I would also like to have that I have never seen /etc/trinity on ANY of the
> > stable versions of TDE, going from 3.5.12 (the first version I've used) to
> > 3.5.13 and 3.5.13.1. Even with the kde-trinity package installed, /etc/trinity
> > wasn't there. If that's an issue, a bug should be filed, though I'm not
> > familiar enough with the inner workings of TDE to feel confident making the bug
> > report. (note: it might be a Debian-specific packaging issue)
> 
> I also use the Trinity from 3.5.12 and ever since I have /etc/trinity folder on
> all machines with Trinity. On my machines I use Debian Squeeze, on the test
> machine I have various Ubuntu versions and everywhere I have a folder
> /etc/trinity.
> 
> As I said before, there is no correct way to have installed Trinity from debian
> / ubuntu packages, and not having /etc/trinity folder. If you do not have the
> folder /etc/trinity, your system is broken.

I must disagree. I have made several fresh installs of Debian since using TDE, each time doing a text-based net-install and then installed xorg and TDE. Also, I have never had apt report any broken packages having been installed, and "apt-get -f install" never asks to install any missing packages. Also, I have never experienced a situation on my Debian install where something was simultaneously broken and working at the same time, which is what is being suggested here -- I have occasionally had individual programs break and not work at all, after which a reinstall fixes this issue. Certainly not the case here.

(Odpověď na komentář #27)
> (In reply to comment #25)
> > (Odpověď na komentář #23)
> > > I would also like to have that I have never seen /etc/trinity on ANY of the
> > > stable versions of TDE, going from 3.5.12 (the first version I've used) to
> > > 3.5.13 and 3.5.13.1. Even with the kde-trinity package installed, /etc/trinity
> > > wasn't there. If that's an issue, a bug should be filed, though I'm not
> > > familiar enough with the inner workings of TDE to feel confident making the bug
> > > report. (note: it might be a Debian-specific packaging issue)
> > 
> > I also use the Trinity from 3.5.12 and ever since I have /etc/trinity folder on
> > all machines with Trinity. On my machines I use Debian Squeeze, on the test
> > machine I have various Ubuntu versions and everywhere I have a folder
> > /etc/trinity.
> > 
> > As I said before, there is no correct way to have installed Trinity from debian
> > / ubuntu packages, and not having /etc/trinity folder. If you do not have the
> > folder /etc/trinity, your system is broken.
> 
> I must disagree. I have made several fresh installs of Debian since using TDE,
> each time doing a text-based net-install and then installed xorg and TDE. Also,
> I have never had apt report any broken packages having been installed, and
> "apt-get -f install" never asks to install any missing packages. Also, I have
> never experienced a situation on my Debian install where something was
> simultaneously broken and working at the same time, which is what is being
> suggested here -- I have occasionally had individual programs break and not
> work at all, after which a reinstall fixes this issue. Certainly not the case
> here.

As I wrote above (comment 21), many packages install files into /etc/trinity. For example, the package kdm-trinity contains folder /etc/trinity/kdm with eight files. Therefore, I repeat, if on your system does not exists folder /etc/trinity, something in your system is wrong.

(In reply to comment #28)
> (Odpověď na komentář #27)
> > (In reply to comment #25)
> > > (Odpověď na komentář #23)
> > > > I would also like to have that I have never seen /etc/trinity on ANY of the
> > > > stable versions of TDE, going from 3.5.12 (the first version I've used) to
> > > > 3.5.13 and 3.5.13.1. Even with the kde-trinity package installed, /etc/trinity
> > > > wasn't there. If that's an issue, a bug should be filed, though I'm not
> > > > familiar enough with the inner workings of TDE to feel confident making the bug
> > > > report. (note: it might be a Debian-specific packaging issue)
> > > 
> > > I also use the Trinity from 3.5.12 and ever since I have /etc/trinity folder on
> > > all machines with Trinity. On my machines I use Debian Squeeze, on the test
> > > machine I have various Ubuntu versions and everywhere I have a folder
> > > /etc/trinity.
> > > 
> > > As I said before, there is no correct way to have installed Trinity from debian
> > > / ubuntu packages, and not having /etc/trinity folder. If you do not have the
> > > folder /etc/trinity, your system is broken.
> > 
> > I must disagree. I have made several fresh installs of Debian since using TDE,
> > each time doing a text-based net-install and then installed xorg and TDE. Also,
> > I have never had apt report any broken packages having been installed, and
> > "apt-get -f install" never asks to install any missing packages. Also, I have
> > never experienced a situation on my Debian install where something was
> > simultaneously broken and working at the same time, which is what is being
> > suggested here -- I have occasionally had individual programs break and not
> > work at all, after which a reinstall fixes this issue. Certainly not the case
> > here.
> 
> As I wrote above (comment 21), many packages install files into /etc/trinity.
> For example, the package kdm-trinity contains folder /etc/trinity/kdm with
> eight files. Therefore, I repeat, if on your system does not exists folder
> /etc/trinity, something in your system is wrong.

So you're saying that even though apt reports broken files in the nightlies repo, that the issue is definitely my system? I'm sorry, I can't accept that. Not only have I been using and closely studying this system for years. Additionally, that ignores the fact that there are other people besides myself whom I have nothing to do with who have also experienced this problem.

The fact that there are broken packages in the nightlies repo, as mentioned above, suggests that it could certainly be the packages. It is also to be expected considering that the nightlies are for testing stuff that isn't fully tested, and for pulling out and fixing issues.

Before blaming my system, please make sure that the packages themselves are not broken, e.g. there shouldn't be any missing dependencies or conflicts between packages, and the package scripts should be reviewed to make sure that all needed files are packaged and installed. If whoever maintains those packages can do that, I'd be happy to reinstall them and test to see if this bug persists.

Otherwise, please do not just blame my system.

P.S. If /etc/trinity is definitely in the stable packages, you might want to talk to the apt developers, that would be the only other place where there is a problem.

Kris, so that I can understand this bug better, please post the output of 'dpkg -L tdm-trinity'.  No one should be blaming you, it is possible that something is subtly wrong in the TDE packaging and we just can't see it at the moment.  It should not be possible to install a broken system that is missing the /etc/trinity folder, yet that is what you are indicating has happened.  We simply need more info to debug this. :-)

Please also send the output from commands:

dpkg -S /etc/trinity

find /etc/trinity | wc -l

Created attachment 1184 [details]
Output for "dpkg -L tdm-trinity"

While it reports /etc/trinity, it definitely non-existent on my system. I have checked. All other files do exist.

When I have a chance, I will will "apt-get --purge remove" all TDE-related packages and install them from scratch, however this could be quite some time. Real life personal issues take priority.

(In reply to comment #31)
> Please also send the output from commands:
> 
> dpkg -S /etc/trinity

tdebase-data-trinity, klipper-trinity, libkleopatra1-trinity, kmail-trinity, ksysguardd-trinity, kexi-trinity, tdelibs-data-trinity, kpowersave-nohal-trinity, kdesktop-trinity, tdebase-trinity-bin, tdm-trinity, konq-plugins-trinity, konqueror-trinity, kate-trinity, kooka-trinity: /etc/trinity
 
> find /etc/trinity | wc -l

0

(In reply to comment #32)
> Created attachment 1184 [details]
> Output for "dpkg -L tdm-trinity"
> 
> While it reports /etc/trinity, it definitely non-existent on my system. I have
> checked. All other files do exist.
> 
> When I have a chance, I will will "apt-get --purge remove" all TDE-related
> packages and install them from scratch, however this could be quite some time.
> Real life personal issues take priority.

Rather than doing that, try 'aptitude reinstall tdm-trinity' and see if it creates the missing entries. 

The only thing I can think of is that something deleted the /etc/trinity directory after it was created, but I don't know what would have had permissions and reason to do so.

Alternatively, you can purge package before reinstall:

dpkg --force-depends --purge tdm-trinity
aptitude reinstall tdm-trinity

Problem is, aptitude isn't installed (I never use it), and I don't have time to wait for it.

I promise I will try as soon as I get the chance, unfortunately I have to leave about 20 minutes ago.

(In reply to comment #36)
> Problem is, aptitude isn't installed (I never use it), and I don't have time to
> wait for it.
> 
> I promise I will try as soon as I get the chance, unfortunately I have to leave
> about 20 minutes ago.

I will also force a fsck before trying. I doubt seriously that the fs is corrupt (I'm not seeing any other signs that there is corruption), but I will do one anyways for the sake of thoroughness.

Right now I have installed on bare system package tdm-trinity and the necessary dependencies (from current nightly-builds):

libdbus-1-tqt libtqt3-mt tdebase-data-trinity libarts1c2a-trinity libdbus-tqt-1-1c2 libartsc0-trinity tdelibs4c2a-trinity tdebase-trinity-bin libart-2.0-2 libtqtinterface tdm-trinity libr0 tdelibs-data-trinity

# find /etc/trinity/ | wc -l
31

(Odpověď na komentář #36)
> Problem is, aptitude isn't installed (I never use it), and I don't have time to
> wait for it.
> 
> I promise I will try as soon as I get the chance, unfortunately I have to leave
> about 20 minutes ago.

Aptitude is not neccessary - you can also use apt-get:

apt-get install --reinstall tdm-trinity

After a "--purge remove" and reinstallation of all TDE-related packages, /etc/trinity appears.

This suggests to me, during some upgrade, that some package removed it. I cannot say whether it was from nightlies -> nightlies or 3.5.13.1 -> nightlies, I can only say that I have seen this using TDE stable, nor with non-TDE packages. Considering all the renamings that have occurred, it is not inconceivable that there may be a typo somewhere in the packaging scripts. I am *not*, however, ready to blame my system for the issue.

On a side note, /etc/tqt3 was there before removal and after reinstallation.

(In reply to comment #40)
<snip>
> This suggests to me, during some upgrade, that some package removed it. I
> cannot say whether it was from nightlies -> nightlies or 3.5.13.1 -> nightlies,
> I can only say that I have seen this using TDE stable, nor with non-TDE
> packages.
<snip>
Correction: I have *never* seen this in TDE stable or elsewhere.

(In reply to comment #40)
> After a "--purge remove" and reinstallation of all TDE-related packages,
> /etc/trinity appears.
> 
> This suggests to me, during some upgrade, that some package removed it. I
> cannot say whether it was from nightlies -> nightlies or 3.5.13.1 -> nightlies,
> I can only say that I have seen this using TDE stable, nor with non-TDE
> packages. Considering all the renamings that have occurred, it is not
> inconceivable that there may be a typo somewhere in the packaging scripts. I am
> *not*, however, ready to blame my system for the issue.
> 
> On a side note, /etc/tqt3 was there before removal and after reinstallation.

I am not ready to blame your system either, as several users have experienced this failure, judging by the CC list on this bug report alone.

The only things I can think of are a.) a package which deletes the /etc/trinity folder by accident or design, or b.) an upgrade script going nuts and deleting the folder.  For b.) to occur you would (likely) have needed to log in to TDE as root at some point; did you log in to TDE as root at all?

For a.) to occur and be the fault of the TDE packaging, I would suspect one of the install/remove scripts in tdebase first.

Slavek, can you see any way for any of the TDE debian packaging scripts to go nuts and remove the /etc/trinity folder?

(In reply to comment #42)
<snip>
> The only things I can think of are a.) a package which deletes the /etc/trinity
> folder by accident or design, or b.) an upgrade script going nuts and deleting
> the folder.  For b.) to occur you would (likely) have needed to log in to TDE
> as root at some point; did you log in to TDE as root at all?
<snip>

No, I have never used TDE as root. The closest I've gotten to that is Fluxbox as root, and for me that's extremely rare.

Any upgrades require root privileges, either via sudo or logged in directly as root, so this is possible provided that the update script is in a package.

This is literally the first time I have done an install of TDE as opposed to an "upgrade" to TDE, e.g. I "upgraded" from KDE 3.5.10 to TDE 3.5.12, and every installation of TDE since has been through an "apt-get dist-upgrade".

Either something is wrong with apt/dpkg and it doesn't correctly extract files from unstable packages, or by chance apt/dpkg got confused with TDE specifically from all the upgrades, or there is an issue with the TDE packaging. From all the people having issues, and because of how well I know my system, the most likely candidate is the last one I mentioned.

Slavek,

This report seems limited to 3.5.13.x and not to affect R14. I am removing this report from the R14 etherpad road map.

(In reply to comment #44)
> Slavek,
> 
> This report seems limited to 3.5.13.x and not to affect R14. I am removing this
> report from the R14 etherpad road map.

If you read through my comments, you'll notice I make reference to this bug ocurring on the nightlies. At that time (and even now, AFAIK), the nightlies were equivalent to R14-alpha/beta. Therefor, I must disagree that it is limited to 3.5.13.x.

Ok. :-)

I have updated the title to make this report a bit clearer.

I noticed that Kris said the /etc/trinity directory was not present on his system going all the way back to TDE 3.5.12.  It is possible that the bug existed in 3.5.12 and that the upgrades never restored the /etc/trinity directory (I am not sure that they should!).  I am loading 3.5.13.2 on a test box and will execute an upgrade to R14 to see if I can replicate this.  I will also try removing the /etc/trinity directory before an upgrade to R14 to see if it is recreated or not.

I passed several tests upgrade 3.5.13.2 => R14 (nightly) and I never noticed the absence of the /etc/trinity.

From what I can tell, if the /etc/trinity directory is present before the upgrade then it will be present after the upgrade.  I am running one more test with a purposefully removed /etc/trinity directory (to simulate a potential failure in an older TDE version) to see if it is recreated during upgrade.

(In reply to comment #49)
> From what I can tell, if the /etc/trinity directory is present before the
> upgrade then it will be present after the upgrade.  I am running one more test
> with a purposefully removed /etc/trinity directory (to simulate a potential
> failure in an older TDE version) to see if it is recreated during upgrade.

The /etc/trinity directory was recreated for me on upgrade to R14.  All tests were on Ubuntu Quantal.

Until someone can show me how exactly this happens, I'm going to mark this WORKSFORME due to my testing and feedback from Slavek.  Perhaps this was something that broke between 3.5.x releases and is now fixed, or perhaps I have not been able to duplicate the failure scenario.  Please feel free to reopen if you can provide more details on how to recreate the problem.

Thanks for reporting!