2

Running Buster on a Pi4, updates, upgrades were just done. Everything was working just dandy then... I shut my Pi down in order to physically move it on my workspace. I reconnected everything exactly as it had been, the same HDMI, USB, and power. When I booted it up, everything seemed OK right up to the password request. After typing my password, the dialog disappeared as it always did but no menus appear, none, not across the top of the screen or the desktop icons. But the desktop image is there. I rebooted again, and again, and again, to no avail. I can right-click and get a dialog box with 'Terminal emulator', 'Web browser', and other items including 'Applications' but nothing in any of them gives me a solution. None of the traditional fixes seem to work. Anyone have an idea what I should try next?

  • 1
    None of the traditional fixes seem to work - which traditional fixes? I'd hate to suggest one of the fixes you've already tried – Jaromanda X Feb 06 '20 at 20:22
  • 1
    I did this: $ sudo rm -r ~/.config/lxpanel $ startx – Keith D Kaiser Feb 06 '20 at 20:54
  • 1
    I tried several other things suggested in forums but thinking each was going to fix things I didn't keep a record of them. I'll take any suggestion you have. – Keith D Kaiser Feb 06 '20 at 20:55
  • 1
    On reboot under the 4 raspberries I get this: "[2.109001] usb 1-1.2.4: device descriptor read/64, error-32 and another, [2.3390631] usb 1-1.2.4: device descriptor read/64, error-32" I don't know if they are related or not. – Keith D Kaiser Feb 06 '20 at 21:12
  • 1
    Are you booting from a SD Card or an external USB-connected device? Try booting into CLI. – user96931 Feb 06 '20 at 21:43
  • 1
    I set it up for CLI. It is booting from the SD Card. Its only a few weeks old, but I've been using it for all that time without any issues. – Keith D Kaiser Feb 06 '20 at 22:09
  • 1
    Are you running the latest version of Raspbian? Have you changed anything in /boot? When is the last time you updated and upgraded your packages? – user96931 Feb 07 '20 at 02:54
  • 1
    Please don't add more and more information by comments. Instead edit your question and add it there. Most reader doesn't read all comments or gather its information. – Ingo Feb 07 '20 at 09:49

2 Answers2

1

I have observed the behavior you described on Debian Desktop installations when the device tried to connect to network resources (NFS exports, network shares) that are not available. The operating system tries a long time to connect and only after a long timeout it gives up and completed the Desktop. You should also find error messages in journalctl -b -e then. In my case it where some NFS connections to a not available server which timed out after about 2 min per connection. So you should wait a long time and look if the Destop finished with a complete user interface. I know, this will not really help you but you know where you have to look. In my case I verified this issue by commenting the network connections in /etc/fstab. If you find that the reason are also network connections then you know what to manage to start your Desktop without delay.

Ingo
  • 42,107
  • 20
  • 85
  • 197
  • 1
    Thanks @Ingo for this. As it happens I have a recent backup of the SD disk causing the problems. So I've switched to the BU and all is well. I'll copy the BU back to the original and hope for the best. – Keith D Kaiser Feb 07 '20 at 17:21
0

The solution to this problem is illusive. So I decided to use the backup I created. Its working great, so I'll just start over with that. Thanks to all who tried to help.

  • Please accept your own answer with a click on the tick on its left side. Only this will finish the question and it will not pop up again year for year. – Ingo Feb 12 '20 at 19:22