I successfully got the key for Slávek Banko's repository in order to authenticate a preliminary stable build of R14.0.1 to use with Jessie. I then installed tde-trinity -- a total of 503 packages.
When the login manager appeared, after selecting TDE as my session type I was able to log in as my user. The default flash screen appeared with seven icons across the bottom. The first four were highlighted briefly.
When the fifth one, “Loading the desktop”, appeared the icon flashed for 50 seconds, then the flash screen disappeared, leaving only the original blue screen with blotches of white of various shapes, the Debian swirl in red and the cursor – nothing else. From this point I could do nothing else.
What I i supposed to do now? Was something was missed in the installation?
Regards, Ken Heard
On Thursday 14 May 2015 21:50:04 Ken Heard wrote:
I successfully got the key for Slávek Banko's repository in order to authenticate a preliminary stable build of R14.0.1 to use with Jessie. I then installed tde-trinity -- a total of 503 packages.
When the login manager appeared, after selecting TDE as my session type I was able to log in as my user. The default flash screen appeared with seven icons across the bottom. The first four were highlighted briefly.
When the fifth one, “Loading the desktop”, appeared the icon flashed for 50 seconds, then the flash screen disappeared, leaving only the original blue screen with blotches of white of various shapes, the Debian swirl in red and the cursor – nothing else. From this point I could do nothing else.
What I i supposed to do now? Was something was missed in the installation?
I think it must be a bug. I have had the same thing happen.
So far, if I get into a virtual console, log in as root and do # init 6 and login again when the login screen reappears, it boots in properly.
It didn't happen before I reinstalled. That was on pre-release Jessie.
All less frustrating solutions gladly welcomed.
Lisi
On Thursday 14 of May 2015 22:58:59 Lisi Reisz wrote:
On Thursday 14 May 2015 21:50:04 Ken Heard wrote:
I successfully got the key for Slávek Banko's repository in order to authenticate a preliminary stable build of R14.0.1 to use with Jessie. I then installed tde-trinity -- a total of 503 packages.
When the login manager appeared, after selecting TDE as my session type I was able to log in as my user. The default flash screen appeared with seven icons across the bottom. The first four were highlighted briefly.
When the fifth one, “Loading the desktop”, appeared the icon flashed for 50 seconds, then the flash screen disappeared, leaving only the original blue screen with blotches of white of various shapes, the Debian swirl in red and the cursor – nothing else. From this point I could do nothing else.
What I i supposed to do now? Was something was missed in the installation?
I think it must be a bug. I have had the same thing happen.
So far, if I get into a virtual console, log in as root and do # init 6 and login again when the login screen reappears, it boots in properly.
It didn't happen before I reinstalled. That was on pre-release Jessie.
All less frustrating solutions gladly welcomed.
Lisi
Unfortunately, it's still the same bug. I'm still not discovered what leads to deadlock:
http://bugs.pearsoncomputing.net/show_bug.cgi?id=2437
I'm using this: 1) Ctrl+Alt+F1 for switch to the text console 2) killall -9 kdesktop 3) switch back to Xorg 4) and then try to start kdesktop again from console
Hi Slavek.
On Friday 15 May 2015 00:45:01 Slávek Banko wrote:
On Thursday 14 of May 2015 22:58:59 Lisi Reisz wrote:
On Thursday 14 May 2015 21:50:04 Ken Heard wrote:
I successfully got the key for Slávek Banko's repository in order to authenticate a preliminary stable build of R14.0.1 to use with Jessie. I then installed tde-trinity -- a total of 503 packages.
When the login manager appeared, after selecting TDE as my session type I was able to log in as my user. The default flash screen appeared with seven icons across the bottom. The first four were highlighted briefly.
When the fifth one, “Loading the desktop”, appeared the icon flashed for 50 seconds, then the flash screen disappeared, leaving only the original blue screen with blotches of white of various shapes, the Debian swirl in red and the cursor – nothing else. From this point I could do nothing else.
What I i supposed to do now? Was something was missed in the installation?
I think it must be a bug. I have had the same thing happen.
So far, if I get into a virtual console, log in as root and do # init 6 and login again when the login screen reappears, it boots in properly.
It didn't happen before I reinstalled. That was on pre-release Jessie.
All less frustrating solutions gladly welcomed.
Lisi
Unfortunately, it's still the same bug. I'm still not discovered what leads to deadlock:
http://bugs.pearsoncomputing.net/show_bug.cgi?id=2437
I'm using this:
- Ctrl+Alt+F1 for switch to the text console
- killall -9 kdesktop
- switch back to Xorg
- and then try to start kdesktop again from console
I'm doing a Ctrl+Alt+Backspace when the blue screen appears, this takes me back to the login screen. From there I can now login normally.
On Friday 15 May 2015 21:57:39 Baron wrote:
Hi Slavek.
I'm using this:
- Ctrl+Alt+F1 for switch to the text console
- killall -9 kdesktop
- switch back to Xorg
- and then try to start kdesktop again from console :
I tried this above but when I come back to the tdm-trinity, boot aborted as before...
I'm doing a Ctrl+Alt+Backspace when the blue screen appears, this takes me back to the login screen. From there I can now login normally :
Also, sorry but if I do "Ctrl+Alt+Backspace" when the blue screen appears, nothing happens, no login screen back. I can only do Ctrl+Alt+F1 for switch to the text console. I type : # tdm-trinity stop # tdm-trinity start No logging again even if I wait for the password disappears, it works sometimes about one / ten times.
So, fed up ! => OpenBox desktop.
Good evening.
André
On Fri, 15 May 2015 22:16:08 +0200 andre_debian@numericable.fr wrote:
On Friday 15 May 2015 21:57:39 Baron wrote:
Hi Slavek.
I'm using this:
- Ctrl+Alt+F1 for switch to the text console
- killall -9 kdesktop
- switch back to Xorg
- and then try to start kdesktop again from console :
I tried this above but when I come back to the tdm-trinity, boot aborted as before...
You mean when you killall kdesktop it does not proceed into half-working session? Then you probably have a different bug...
On Friday 15 May 2015 22:39:12 Nick Koretsky wrote:
On Fri, 15 May 2015 22:16:08 +0200 andre_debian@numericable.fr wrote:
On Friday 15 May 2015 21:57:39 Baron wrote:
Hi Slavek.
I'm using this:
- Ctrl+Alt+F1 for switch to the text console
- killall -9 kdesktop
- switch back to Xorg
- and then try to start kdesktop again from console :
I tried this above but when I come back to the tdm-trinity, boot aborted as before...
You mean when you killall kdesktop it does not proceed into half-working session? Then you probably have a different bug...
The bug is the same than the others.
It's only that the solutions proposed to proceed full working does not work for me :
1] (text console) killall -9 kdesktop 2] Ctrl+Alt+Backspace
André
On Fri, 15 May 2015 22:54:21 +0200 andre_debian@numericable.fr wrote:
On Friday 15 May 2015 22:39:12 Nick Koretsky wrote:
On Fri, 15 May 2015 22:16:08 +0200 andre_debian@numericable.fr wrote:
On Friday 15 May 2015 21:57:39 Baron wrote:
Hi Slavek.
I'm using this:
- Ctrl+Alt+F1 for switch to the text console
- killall -9 kdesktop
- switch back to Xorg
- and then try to start kdesktop again from console :
I tried this above but when I come back to the tdm-trinity, boot aborted as before...
You mean when you killall kdesktop it does not proceed into half-working session? Then you probably have a different bug...
The bug is the same than the others.
It's only that the solutions proposed to proceed full working does not work for me :
1] (text console) killall -9 kdesktop 2] Ctrl+Alt+Backspace
Um, no. The bug everyone is having is a deadlock at kdesktop start. While various methods of restarting tdm may or may not help depending on unknown factors (Slavek have not yet found why the lock is happening in the first place), killall -9 kdesktop should work in 100% cases (It should get you a working kicker without desktop functionality). If in your case killing kdesktop doesnt work it means it hangs in a completely different place.
On Friday 15 May 2015 20:57:39 Baron wrote:
Hi Slavek.
On Friday 15 May 2015 00:45:01 Slávek Banko wrote:
On Thursday 14 of May 2015 22:58:59 Lisi Reisz wrote:
On Thursday 14 May 2015 21:50:04 Ken Heard wrote:
I successfully got the key for Slávek Banko's repository in order to authenticate a preliminary stable build of R14.0.1 to use with Jessie. I then installed tde-trinity -- a total of 503 packages.
When the login manager appeared, after selecting TDE as my session type I was able to log in as my user. The default flash screen appeared with seven icons across the bottom. The first four were highlighted briefly.
When the fifth one, “Loading the desktop”, appeared the icon flashed for 50 seconds, then the flash screen disappeared, leaving only the original blue screen with blotches of white of various shapes, the Debian swirl in red and the cursor – nothing else. From this point I could do nothing else.
What I i supposed to do now? Was something was missed in the installation?
I think it must be a bug. I have had the same thing happen.
So far, if I get into a virtual console, log in as root and do # init 6 and login again when the login screen reappears, it boots in properly.
It didn't happen before I reinstalled. That was on pre-release Jessie.
All less frustrating solutions gladly welcomed.
Lisi
Unfortunately, it's still the same bug. I'm still not discovered what leads to deadlock:
http://bugs.pearsoncomputing.net/show_bug.cgi?id=2437
I'm using this:
- Ctrl+Alt+F1 for switch to the text console
- killall -9 kdesktop
- switch back to Xorg
- and then try to start kdesktop again from console
I'm doing a Ctrl+Alt+Backspace when the blue screen appears, this takes me back to the login screen. From there I can now login normally.
I tried that. Didn't work. Only VT works. Otherwise the whole thing is frozen.
I haven't tried killall yet, but I'm sure that it will work.
Lisi
Hi
Hi Slavek.
On Friday 15 May 2015 00:45:01 Slávek Banko wrote:
On Thursday 14 of May 2015 22:58:59 Lisi Reisz wrote:
On Thursday 14 May 2015 21:50:04 Ken Heard wrote:
I successfully got the key for Slávek Banko's repository in order to authenticate a preliminary stable build of R14.0.1 to use with Jessie. I then installed tde-trinity -- a total of 503 packages.
When the login manager appeared, after selecting TDE as my session type I was able to log in as my user. The default flash screen appeared with seven icons across the bottom. The first four were highlighted briefly.
When the fifth one, “Loading the desktop”, appeared the icon flashed for 50 seconds, then the flash screen disappeared, leaving only the original blue screen with blotches of white of various shapes, the Debian swirl in red and the cursor – nothing else. From this point I could do nothing else.
What I i supposed to do now? Was something was missed in the installation?
I think it must be a bug. I have had the same thing happen.
So far, if I get into a virtual console, log in as root and do # init 6 and login again when the login screen reappears, it boots in properly.
It didn't happen before I reinstalled. That was on pre-release Jessie.
All less frustrating solutions gladly welcomed.
Lisi
Unfortunately, it's still the same bug. I'm still not discovered what leads to deadlock:
http://bugs.pearsoncomputing.net/show_bug.cgi?id=2437
I'm using this:
- Ctrl+Alt+F1 for switch to the text console
- killall -9 kdesktop
- switch back to Xorg
- and then try to start kdesktop again from console
Insted start kdesktop try: /etc/init.d/tde-trinity restart. It works here
Fine regards Rolf
On Saturday 16 May 2015 12:19:10 am Rolf Schmidt wrote:
I'm using this:
- Ctrl+Alt+F1 for switch to the text console
- killall -9 kdesktop
- switch back to Xorg
- and then try to start kdesktop again from console
Insted start kdesktop try: /etc/init.d/tde-trinity restart. It works here
Fine regards Rolf
One more option..I switched to using 'service', it has command line completion. man service
#'service tdm-trinity <stop/start/restart>"
On Saturday 16 May 2015 10:19:10 Rolf Schmidt wrote:
Instead start kdesktop try: /etc/init.d/tde-trinity restart. It works here Rolf
Hello,
"tde-trinity" doesn't exist in "/etc/init.d", but "/etc/init.d/tdm-trinity".
You mean when you killall kdesktop it does not proceed into half-working session? Then you probably have a different bug...
Um, no. The bug everyone is having is a deadlock at kdesktop start. While various methods of restarting tdm may or may not help depending on unknown factors (Slavek have not yet found why the lock is happening in the first place), killall -9 kdesktop should work in 100% cases (It should get you a working kicker without desktop functionality). If in your case killing kdesktop doesnt work it means it hangs in a completely different place.
My booting bug logging stopping is quite the same as the others. It's not because a solution doesn't work that the bug could be differrent.
Do CTRL-ALT-BACKSPACE => back to the tdm-trinity or text console, is an option that I have enabled.
1] CTRL-ALT-BACKSPACE, logging again, or 2] killall Desktop, or 3] waiting the password disappears,
doesn't not solve the problem of the logging aborting, or sometimes, about one of ten tentatives, it's not acceptable.
André
Similar problem here (Jessie with no *systemd* + TDE R14). It happens about one time in ten.
# get console su service tdm-trinity restart && exit
sorts it here.. I can live with that till it's fixed, the pleasure to have TDE running is worth it.
D
On Sunday 17 May 2015 13:54:02 andre_debian@numericable.fr wrote:
On Saturday 16 May 2015 10:19:10 Rolf Schmidt wrote:
Instead start kdesktop try: /etc/init.d/tde-trinity restart. It works here Rolf
Hello,
"tde-trinity" doesn't exist in "/etc/init.d", but "/etc/init.d/tdm-trinity".
You mean when you killall kdesktop it does not proceed into half-working session? Then you probably have a different bug...
Um, no. The bug everyone is having is a deadlock at kdesktop start. While various methods of restarting tdm may or may not help depending on unknown factors (Slavek have not yet found why the lock is happening in the first place), killall -9 kdesktop should work in 100% cases (It should get you a working kicker without desktop functionality). If in your case killing kdesktop doesnt work it means it hangs in a completely different place.
My booting bug logging stopping is quite the same as the others. It's not because a solution doesn't work that the bug could be differrent.
Do CTRL-ALT-BACKSPACE => back to the tdm-trinity or text console, is an option that I have enabled.
1] CTRL-ALT-BACKSPACE, logging again, or 2] killall Desktop, or 3] waiting the password disappears,
doesn't not solve the problem of the logging aborting, or sometimes, about one of ten tentatives, it's not acceptable.
We're probably onto English not first language territory again but...
André, there is a bug. You have been told which workarounds work for the bug. The rest of us are using the workarounds for now and the developers are working on finding a solution. When they find a solution we shall have the patch and we shall not have the problem. Until then we continue to use the workarounds.
That is the situation. If it is not acceptable, don't accept it. But either do something about it yourself or don't. There is no point in going on and on about it. We note that you find it unacceptable. So what then??
That is the situation. Accept it or don't. Those are the alternatives.
Lisi
On Sunday 17 May 2015 15:11:20 Lisi Reisz wrote:
My booting bug logging stopping is quite the same as the others. It's not because a solution doesn't work that the bug could be differrent. Do CTRL-ALT-BACKSPACE => back to the tdm-trinity or text console, is an option that I have enabled. 1] CTRL-ALT-BACKSPACE, logging again, or 2] killall Desktop, or 3] waiting the password disappears, doesn't not solve the problem of the logging aborting, or sometimes, about one of ten tentatives, it's not acceptable.
We're probably onto English not first language territory again but... André, there is a bug. You have been told which workarounds work for the bug. The rest of us are using the workarounds for now and the developers are working on finding a solution. When they find a solution we shall have the patch and we shall not have the problem. Until then we continue to use the workarounds. That is the situation. If it is not acceptable, don't accept it. But either do something about it yourself or don't. There is no point in going on and on about it. We note that you find it unacceptable. So what then?? That is the situation. Accept it or don't. Those are the alternatives. Lisi
"one success on ten unsuccessfull tentatives is not acceptable" = in the meantime, I use OpenBox desktop, wait kindly for a solution, understands and thanks the work of the TDE team.
André
On Sunday 17 May 2015 05:11:20 am Lisi Reisz wrote:
On Sunday 17 May 2015 13:54:02 andre_debian@numericable.fr wrote:
On Saturday 16 May 2015 10:19:10 Rolf Schmidt wrote:
Instead start kdesktop try: /etc/init.d/tde-trinity restart. It works here Rolf
Hello,
"tde-trinity" doesn't exist in "/etc/init.d", but "/etc/init.d/tdm-trinity".
You mean when you killall kdesktop it does not proceed into half-working session? Then you probably have a different bug...
Um, no. The bug everyone is having is a deadlock at kdesktop start. While various methods of restarting tdm may or may not help depending on unknown factors (Slavek have not yet found why the lock is happening in the first place), killall -9 kdesktop should work in 100% cases (It should get you a working kicker without desktop functionality). If in your case killing kdesktop doesnt work it means it hangs in a completely different place.
My booting bug logging stopping is quite the same as the others. It's not because a solution doesn't work that the bug could be differrent.
Do CTRL-ALT-BACKSPACE => back to the tdm-trinity or text console, is an option that I have enabled.
1] CTRL-ALT-BACKSPACE, logging again, or 2] killall Desktop, or 3] waiting the password disappears,
doesn't not solve the problem of the logging aborting, or sometimes, about one of ten tentatives, it's not acceptable.
We're probably onto English not first language territory again but...
André, there is a bug. You have been told which workarounds work for the bug. The rest of us are using the workarounds for now and the developers are working on finding a solution. When they find a solution we shall have the patch and we shall not have the problem. Until then we continue to use the workarounds.
That is the situation. If it is not acceptable, don't accept it. But either do something about it yourself or don't. There is no point in going on and on about it. We note that you find it unacceptable. So what then??
That is the situation. Accept it or don't. Those are the alternatives.
Lisi
One more case to round out solutions, my main install is my workstation, it runs all the time.
I also do not use 'kdesktop_lock', it does not work with my Nvidia card drivers from Nvidia ...maybe video related?
On Monday 18 May 2015 03:21:19 Greg Madden wrote:
On Sunday 17 May 2015 05:11:20 am Lisi Reisz wrote:
On Sunday 17 May 2015 13:54:02 andre_debian@numericable.fr wrote:
On Saturday 16 May 2015 10:19:10 Rolf Schmidt wrote:
Instead start kdesktop try: /etc/init.d/tde-trinity restart. It works here Rolf
Hello,
"tde-trinity" doesn't exist in "/etc/init.d", but "/etc/init.d/tdm-trinity".
You mean when you killall kdesktop it does not proceed into half-working session? Then you probably have a different bug...
Um, no. The bug everyone is having is a deadlock at kdesktop start. While various methods of restarting tdm may or may not help depending on unknown factors (Slavek have not yet found why the lock is happening in the first place), killall -9 kdesktop should work in 100% cases (It should get you a working kicker without desktop functionality). If in your case killing kdesktop doesnt work it means it hangs in a completely different place.
My booting bug logging stopping is quite the same as the others. It's not because a solution doesn't work that the bug could be differrent.
Do CTRL-ALT-BACKSPACE => back to the tdm-trinity or text console, is an option that I have enabled.
1] CTRL-ALT-BACKSPACE, logging again, or 2] killall Desktop, or 3] waiting the password disappears,
doesn't not solve the problem of the logging aborting, or sometimes, about one of ten tentatives, it's not acceptable.
We're probably onto English not first language territory again but...
André, there is a bug. You have been told which workarounds work for the bug. The rest of us are using the workarounds for now and the developers are working on finding a solution. When they find a solution we shall have the patch and we shall not have the problem. Until then we continue to use the workarounds.
That is the situation. If it is not acceptable, don't accept it. But either do something about it yourself or don't. There is no point in going on and on about it. We note that you find it unacceptable. So what then??
That is the situation. Accept it or don't. Those are the alternatives.
Lisi
One more case to round out solutions, my main install is my workstation, it runs all the time.
Yes, I thought of suggesting that one!!
Lisi
I also do not use 'kdesktop_lock', it does not work with my Nvidia card drivers from Nvidia ...maybe video related?
On 05/14/2015 01:50 PM, Ken Heard wrote:
When the fifth one, “Loading the desktop”, appeared the icon flashed for 50 seconds, then the flash screen disappeared, leaving only the original blue screen
It started happening to me after the last kernel update. A few other things updated at the same time, including some Trinity stuff, and I'm traveling and haven't had the internet access or time to try to debug it, so I don't know for sure that it's the kernel.
I went back to the earlier version of the 64-bit kernel, and then it started once, but since then the problem is still occurring. For the moment I'm working around it by using the 486 kernel, which I also have installed, and which works.
I'll figure it out when I get home in a few days; hopefully someone else will have come up with a solution in the meantime.
One pet peeve I have with Debian is the (as far as I know) inability to have more than one version of kernel installed at a time, so you can choose an older version at boot time. That makes it a lot easier to debug kernel-related issues. You can have 486/686/AMD64/whatever all installed, but only one version of each.
On Thu May 14 2015 14:24:55 Dan Youngquist wrote:
One pet peeve I have with Debian is the (as far as I know) inability to have more than one version of kernel installed at a time, so you can choose an older version at boot time.
FWIW Debian does permit multiple kernels. The first three packages here are actual kernels and the last is a meta-package to ensure that the main kernel is updated when needed.
# dpkg -l | grep linux-image ii linux-image-2.6.32-5-686 2.6.32-48squeeze6 i386 Linux 2.6.32 for modern PCs ii linux-image-3.2.0-4-686-pae 3.2.68-1+deb7u1 i386 Linux 3.2 for modern PCs ii linux-image-3.2.46 3.2.46-1 i386 Linux kernel, version 3.2.46 ii linux-image-686-pae 3.2+46 i386 Linux for modern PCs (meta-package) #
--Mike
On Thursday 14 May 2015 22:24:55 Dan Youngquist wrote:
One pet peeve I have with Debian is the (as far as I know) inability to have more than one version of kernel installed at a time, so you can choose an older version at boot time. That makes it a lot easier to debug kernel-related issues. You can have 486/686/AMD64/whatever all installed, but only one version of each.
I have several installed at the same time (both Wheezy and Jessie and everything I have used before) and can choose in GRUB. (I only don't have more because I don't want more than four or five.) I can certainly choose an older version at boot time.
Lisi
On Thursday 14 May 2015 22:56:20 Lisi Reisz wrote:
On Thursday 14 May 2015 22:24:55 Dan Youngquist wrote:
One pet peeve I have with Debian is the (as far as I know) inability to have more than one version of kernel installed at a time, so you can choose an older version at boot time. That makes it a lot easier to debug kernel-related issues. You can have 486/686/AMD64/whatever all installed, but only one version of each.
I have several installed at the same time (both Wheezy and Jessie and everything I have used before) and can choose in GRUB. (I only don't have more because I don't want more than four or five.) I can certainly choose an older version at boot time.
I should have said: On this box I have:
lisi@Tux-II:~$ dpkg --list | grep linux-image ii linux-image-3.16-0.bpo.2-amd64 3.16.3-2~bpo70+1 amd64 Linux 3.16 for 64-bit PCs ii linux-image-3.16-0.bpo.3-amd64 3.16.5-1~bpo70+1 amd64 Linux 3.16 for 64-bit PCs ii linux-image-3.16.0-0.bpo.4-amd64 3.16.7-ckt9-3~deb8u1~bpo70+1 amd64 Linux 3.16 for 64-bit PCs ii linux-image-3.2.0-4-amd64 3.2.68-1+deb7u1 amd64 Linux 3.2 for 64-bit PCs ii linux-image-amd64 3.16+63~bpo70+1 amd64 Linux for 64-bit PCs (meta-package) lisi@Tux-II:~$
Lisi
On 05/14/2015 02:56 PM, Lisi Reisz wrote:
I have several installed at the same time (both Wheezy and Jessie and everything I have used before) and can choose in GRUB. (I only don't have more because I don't want more than four or five.) I can certainly choose an older version at boot time.
Strange... Whenever I've tried to install any other version, it wants to uninstall everything else. I just tried to install the 3.16 amd64 from backports, and Synaptic wants to uninstall everything 3.2.0 -- 486, amd64, metapackage, everything. One more thing to figure out when I get home, I suppose.
On Thursday 14 May 2015 23:11:08 Dan Youngquist wrote:
On 05/14/2015 02:56 PM, Lisi Reisz wrote:
I have several installed at the same time (both Wheezy and Jessie and everything I have used before) and can choose in GRUB. (I only don't have more because I don't want more than four or five.) I can certainly choose an older version at boot time.
Strange... Whenever I've tried to install any other version, it wants to uninstall everything else. I just tried to install the 3.16 amd64 from backports, and Synaptic wants to uninstall everything 3.2.0 -- 486, amd64, metapackage, everything. One more thing to figure out when I get home, I suppose.
Perhaps try another package manager. Perhaps it's a Synaptic quirk. I use aptitude and have never had any problem installing extra kernels. I have to uninstall some periodically because they pile up with upgrades!
You talk of Synaptic trying to uninstall multiple kernels, so multiple kernels must be there in the first place, so you must have managed to install them.
As you see, I have both 3.2, and 3.16 from backports. Here is my list again on this box:
lisi@Tux-II:~$ dpkg --list | grep linux-image ii linux-image-3.16-0.bpo.2-amd64 3.16.3-2~bpo70+1 amd64 Linux 3.16 for 64-bit PCs ii linux-image-3.16-0.bpo.3-amd64 3.16.5-1~bpo70+1 amd64 Linux 3.16 for 64-bit PCs ii linux-image-3.16.0-0.bpo.4-amd64 3.16.7-ckt9-3~deb8u1~bpo70+1 amd64 Linux 3.16 for 64-bit PCs ii linux-image-3.2.0-4-amd64 3.2.68-1+deb7u1 amd64 Linux 3.2 for 64-bit PCs ii linux-image-amd64 3.16+63~bpo70+1 amd64 Linux for 64-bit PCs (meta-package) lisi@Tux-II:~$
Lisi
On Thursday 14 May 2015 22:50:04 Ken Heard wrote:
I successfully got the key for Slávek Banko's repository in order to authenticate a preliminary stable build of R14.0.1 to use with Jessie. I then installed tde-trinity -- a total of 503 packages. When the login manager appeared, after selecting TDE as my session type I was able to log in as my user. The default flash screen appeared with seven icons across the bottom. The first four were highlighted briefly. When the fifth one, “Loading the desktop”, appeared the icon flashed for 50 seconds, then the flash screen disappeared, leaving only the original blue screen with blotches of white of various shapes, the Debian swirl in red and the cursor – nothing else. From this point I could do nothing else. What I i supposed to do now? Was something was missed in the installation? Regards, Ken Heard
I confirm that I have the same above described bug since I'am on Jessie 32 bits. Sometimes, very rarely, it boots normally.
On my laptop 64 bits Jessie, this bug doesn't exist.
With Wheezy, the boot worked perfectly.
Bug due to Jessie or TDE-Trinity last version ?
More to follow / To be continued in the coming days... because it's very boring.
André
-
andre_debian＠numericable.fr -
Baron -
Dan Youngquist -
David Hare -
Greg Madden -
Ken Heard -
Lisi Reisz -
Mike Bird -
Nick Koretsky -
Rolf Schmidt -
Slávek Banko