Desktop not loading - tried everything but still just a black screen

[MoonRise]

Well, that seems to be pointed to the correct release. I really am not sure past that. Makes no sense that it would say not all Shell items are installed.

I know you said you did the reinstall of the Desktop but can you run

sudo apt-get update

and then

sudo apt-get -f install kubuntu-full

See if any errors are visible here during that.

[Enigma0]

Well, that seems to be pointed to the correct release. I really am not sure past that. Makes no sense that it would say not all Shell items are installed.

I know you said you did the reinstall of the Desktop but can you run

sudo apt-get update

and then

sudo apt-get -f install kubuntu-full

See if any errors are visible here during that.

Certainly:

:~$ sudo apt-get -f install kubuntu-desktop
Reading package lists... Done
Building dependency tree
Reading state information... Done
kubuntu-desktop is already the newest version (1.344).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
:~$ sudo apt-get -f install kubuntu-full
Reading package lists... Done
Building dependency tree
Reading state information... Done
kubuntu-full is already the newest version (1.344).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

[Snowhog]

Reboot back into a recovery session.

Move the .kde hidden folder in your user home directory: mv /home/your_username/.kde /home/your_username/.kdeNOTWORKING (replace your_username with your login username). Reboot: shutdown -r now

Assuming that something within your user home directory is causing your issues, this will cause a new, default, .kde directory to be built and should allow a Desktop top to start up correctly. If it doesn't; you still have the same issue; the content of the original .kde directory is preserved.

[wizard10000]

Reboot back into a recovery session.

Move the .kde hidden folder in your user home directory: mv /home/your_username/.kde /home/your_username/.kdeNOTWORKING (replace your_username with your login username). Reboot: shutdown -r now

Assuming that something within your user home directory is causing your issues, this will cause a new, default, .kde directory to be built and should allow a Desktop top to start up correctly. If it doesn't; you still have the same issue; the content of the original .kde directory is preserved.

I think in 16.04 and higher he's gonna have to rename ~/.config as well. Might be easier to temporarily create another user.

[Enigma0]

I have tried deleting .kde and .config already (mentioned .config in OP but forgot .kde)

Sadly, this didn't fix the issue either.

:~$ ls -l .
./                         .cache/                    .esd_auth                  .gtkrc-2.0                 .mozilla/                  .psensor/                  .subversion/               .xsession-errors
../                        .conan/                    .FBReader/                 .gvfs/                     .nv/                       .qt/                       .sudo_as_admin_successful
.bash_history              .config_OLD/               .gconf/                    .kde_old/                  .pki/                      .QtWebEngineProcess/       .thumbnails/
.bash_logout               .dbus/                     .gksu.lock                 .lastpass/                 .plexmediaplayer/          .recently-used.xbel        .vmware/
.bashrc                    .directory                 .gnupg/                    .local/                    .profile                   .ssh/                      .Xauthority

[Snowhog]

From the recovery session, verify ownership of your user home directory contents: ls -laR /home/your_username | grep root

Does it identify any files or directories as being owned by root?

[Enigma0]

From the recovery session, verify ownership of your user home directory contents: ls -laR /home/your_username | grep root

Does it identify any files or directories as being owned by root?

That command has a lot of results. I tried to append > results.txt to get it all into a file (going over putty atm which has an output limit) but that may need some trickery to work around the grep pipe maybe?

Should everything in ~/. be owned by that user?

[Snowhog]

When you are booted to a recover session, you are operating 'as root'. Running the command I provided: ls -laR /home/your_username | grep root, replacing your_username with your login username, should return only one item:

drwxr-xr-x 4 root root 4096 Dec 17 2015 .. (what mine returns)

You want to choose network from the recovery session display choices first (it will run and return you back to the menu) and then select root and then redo the command above.

[wizard10000]

...Should everything in ~/. be owned by that user?

For all practical purposes, yes. As someone else mentioned in another thread if there's an ~/.rpmdb in your home directory (running a Debian-based distribution there shouldn't be) that would be owned by root but other than that everything in a user's home directory should be owned by that user.
So - as that user:

cd ~
sudo chown -R [I]username[/I]:[I]username[/I] *

should set home directory file permissions correctly.

Hope this helps -

[Snowhog]

For all practical purposes, yes. As someone else mentioned in another thread if there's an ~/.rpmdb in your home directory (running a Debian-based distribution there shouldn't be) that would be owned by root but other than that everything in a user's home directory should be owned by that user.
So - as that user:

cd ~
sudo chown -R [I]username[/I]:[I]username[/I] *

should set home directory file permissions correctly.

Hope this helps -

NO!!

See my last reply about choosing network first! IF YOU DON'T AND YOU RUN THE COMMAND ABOVE, YOU WILL MESS UP YOUR SYSTEM BEYOND REPAIR!!!

[Enigma0]

NO!!

See my last reply about choosing network first! IF YOU DON'T AND YOU RUN THE COMMAND ABOVE, YOU WILL MESS UP YOUR SYSTEM BEYOND REPAIR!!!

I'm confused by this. Why does networking matter when changing file/folder permissions?

Also is that a no outright or just a no as in not quite like that but like this?

[wizard10000]

You're right about doing that as root, which is why I suggested doing it as the impacted user. I'm gonna go sit back down now

[Snowhog]

The problem/concern is that unless you choose network from a recovery session FIRST, you aren't loading the contents of the /etc/fstab file, and so, won't have the home directory of the non-root user mounted. Thus, running the indicated command 'in this condition' will totally trash your system. :0

[Snowhog]

I'm confused by this. Why does networking matter when changing file/folder permissions?

Also is that a no outright or just a no as in not quite like that but like this?

It's an outright NO!! In other words, IF you boot into a recovery session and don't run network from the menu first, you aren't loading the /etc/fstab file, and won't have the non-root users /home directory mounted. Running the command given by wizard10000 under those conditions would change the ownership of every file in and under the /root directory to your username. This would render your system useless.

See reply #28.

[Enigma0]

Gotcha. Ok I had one git pulldown folder that had most of the contents owned by root which shouldn't have any impact on my issue but was muddling the results. Here's the updated results:

ls -laR /home/[USER]/ | grep root
drwxr-xr-x  3 root   root     4096 Jul 30 12:31 ..
drwx------  2 root   root     4096 Oct  3 22:40 .gvfs
-rw-------  1 root   root    2125 Jul 31 10:53 katemetainfos
-rw-------  1 root   root    1592 Jul 30 12:47 katepartrc
-rw-------  1 root   root     533 Jul 31 01:48 katerc
-rw-------  1 root   root     419 Jul 30 12:50 katevirc
-rw-rw-r--  1 root   root     943 Jul 30 21:35 QtProject.conf
-rw-r--r--  1 root   root   4632 Dec 22 10:33 user
-rw-------  1 root   root         1024 Jul 30 14:30 ~
drwx------  2 root   root   4096 Oct  3 22:40 .
drwxr-xr-x  3 root   root   4096 Jul 31 10:53 kate
-rw-------  1 root   root   1405 Dec 22 10:33 recently-used.xbel
drwxr-xr-x  3 root   root   4096 Jul 31 10:53 .
-rw-------  1 root   root   3919 Jul 31 10:53 anonymous.katesession
drwxr-xr-x  2 root   root   4096 Jul 30 12:47 sessions
drwxr-xr-x 2 root root 4096 Jul 30 12:47 .
drwxr-xr-x 3 root root 4096 Jul 31 10:53 ..