[Solved] [XFCE4] Desktop is displayed +5 min after login

[hedon]

Paxmark...good advice, but I have already done all that.  Thanks to the good advice in other threads on this forum, I got

Code Select Expand

systemd-analyze time and

Code Select Expand

systemd-analyze blame to indicate a 6 second boot to desktop (inclusive of kernel AND userspace).  However, despite the systemd-analyze results, only the wallpaper shows for approximately 1-3 minutes after lightdm login.  It seems to vary in time, but even the fastest desktop appearance is excruciatingly SLOW...

However, pavroos suggestion to install the Sparky kernel and boot with that has resolved the issue!  Good call pavroo!

While I consider this resolved (at least for me), I'm wondering why Sparky doesn't install with it's own Sparky kernel?  Before I followed pavroos advice, I verified with

Code Select Expand

uname -a that Sparky was indeed booting with a Debian 4.18.0 kernel.  I was just surprised that the default install kernel is Debians, rather than Sparky.  I'm an Lubuntu refugee, looking for a new distro with rolling capability, so optional kernel choices are kind of a new thing for me, other than low-latency or liquorix choices.  Educate me please!

With all that said, I'd like to take a moment and say THANKS to pavroo and other Sparky devs for a FANTASTIC offering of LXQt, which I'm REALLY liking...A LOT!  Although my daily driver is Lubuntu, I provide tech support and administer NUMEROUS machines for friends & family.  They use whatever I use, but I'm truly tired of re-installing approximately 20+ fixed release distros every 3+ years; so I'm looking to go rolling release, but stay in the familiar Debian family, if at all possible.  And while I absolutely LOVE the LXDE environment, I see the handwriting on the wall and recognize that LXQt is the future; the faster the uptake of LXQt, the faster the demise (or gtk3 fork) of LXDE.  And with Lubuntu making the switch to LXQt in the soon-to-be-release 18.10 offering, I think there will be a huge influx of LXQt users in the next 2-20 months. 

So I'm shopping for a new LXQt-based rolling-release distro that I can port my heavily customized LXDE-OpenBox-FluxBox-PekWM desktop to.  And the fact that Sparky is Debian-based is a bonus, and the polish of the LXQt desktop is a bonus, but the apparent responsiveness and troubleshooting ability of an active and thriving community with devs in the forum amongst us is a HUGE consideration!  I can't seem to say enough good things about what I see here in the Sparky community.  KUDOS on a job well-done!  I've been looking and experimenting with numerous distros for almost 2 years.  But now I'm thinking that perhaps I might have found MY perfect choice of distro?  I'll certainly be sticking around for awhile!   8)

[paxmark1]

So - pavroo brewed a better 4.18 than Debian for some purposes. That is a great job.   4.18 has been biting a few people in the butt for various issues from what I have seen in Siduction, a good place to lurk for those of us in testing- Sparky 5. 

https://github.com/orgs/lxqt/people     are always interested in help. 
#lxqt on OFTC for user support     for quick fixes. 

Fluxbox additions nice.   You do know that you are much more accomplished than I in Linux.  I just keep plugging systemd and command line fixes I know by heart and remember old mistakes I made (running out of space on root, etc.) 

[hedon]

So - pavroo brewed a better 4.18 than Debian for some purposes. That is a great job.   4.18 has been biting a few people in the butt for various issues from what I have seen in Siduction, a good place to lurk for those of us in testing- Sparky 5. 

https://github.com/orgs/lxqt/people     are always interested in help. 
#lxqt on OFTC for user support     for quick fixes. 

Fluxbox additions nice.   You do know that you are much more accomplished than I in Linux.  I just keep plugging systemd and command line fixes I know by heart and remember old mistakes I made (running out of space on root, etc.)

Haha...you would be quite mistaken.  I usually don't have a clue what I'm doing, but I'm fairly good at the logical isolation of troubleshooting components, and I can google pretty well, and I have a knack for finding people like pavroo who really DO know what they're doing!  As for me, I'm just a persistently stubborn hacker-type who keeps plugging away until I get the desired result, or until I find a workaround while someone else figures it out.  LOL!

I'm quite enamored with LXQt and see the long-term implications, but the lack of documentation and a knowledge base is quite frustrating.  I'm hoping that an influx of LXQt users will spurn more LXQt development, which will in turn improve the documentation.  I'll contribute what I can, where I can, but right now my head is swimming with LXQt issues.  I can hack an LXDE desktop like nobody's business, then try to apply that to LXQt only to find that feature "hasn't been implemented yet."  Grrrr....  I keep telling myself to be patient and it will mature, much like LXDE did.

In the meantime, good advice regarding the Siduction forums.  I really like Siduction LXQT, but even Sid devs recommend against using Siduction for production machines.  But that's what lead me to Sparky, and it's looking more and more like Sparky is a better long-term fit for me!  But I'll continue to watch SID (Still In Development!), as whatever is in Sid today will likely filter to Sparky tomorrow.

I see your and pavroos posts all over this forum, helping others with issue.  I hope to contribute what I can, when I can, according to my ability; at least as much if not more than I require.  I hope... 

[armakolas]

The same problem has occured to all my last installations.
The problem: black screen after login, even if autologin is set, a few minutes of waiting untill the desktop is shown. The only bypass was to press random keys or to move the mouse pointer.

PC 1: Sparky LXQT (testing) installed in my 32bit laptop (ssd, ddr2). It started in the summer of 2018. It had the 4.16 or 4.17 kernel at that time. It is always fully updated. I still have to wait  some minutes untill it shows the desktop.

PC 2 (triple installation): Sparky LXQT (testing) installed in my 32bit desktop (ssd, ddr2). It was installed one month ago from sparkylinux-5.6-i686-pae-minimalcli.iso. It was always fully updated. I always had to wait some minutes untill it showed the desktop. I deleted it yesterday. I reinstalled it from the latest 5.6.1minimalcli.iso (testing) but with the MATE desktop this time. No luck. The same problem. I reinstalled it today, again from the same 5.6.1minimalcli.iso (testing) but with Cinnamon. The same problem again, The only difference in Cinnamon is that the screen is blue  instead of black, as if it is almost ready to show the desktop.

I am thinking of abandoning the use of testing isos, in favor of the stable isos, if they prove that they do not suffer from the same problem. I am frustrated.

[lami07]

Basic question. Have you tried Sparky kernel?

[armakolas]

uname -r gives: 4.20.0-sparky-686-pae (in cinnamon testing 32bit)

Is this a sparky kernel? I have not installed a sparky kernel.
I wish I am wrong.

inxi gives:
CPU: Single Core Intel Pentium 4 (-MT-) speed/min/max: 2800/2800/3400 MHz
Kernel: 4.20.0-sparky-686-pae i686 Up: 6m Mem: 590.9/1945.6 MiB (30.4%)
Storage: 111.79 GiB (3.3% used) Procs: 162 Shell: bash 4.4.23 inxi: 3.0.29

[lami07]

The problem is not any session manager related itself.
Found a solution, simply run:

Code Select Expand

sudo apt purge libpam-gnome-keyring
sudo reboot
and let me know does it help, please.

This solution, provided by Pavroo, helped original poster with his problem. Have you tried it too?

[Bluewater]

Hello everyone,

i had the same problem with Manjaro KDE.
My solution was

Code Select Expand

sudo apt-get install haveged
and

Code Select Expand

sudo systemctl enable haveged.service
sudo systemctl start haveged.service
Maybe it will help you too.

[lami07]

My solution was

Code Select Expand

sudo apt-get install haveged
and

Code Select Expand

sudo systemctl enable haveged.service
sudo systemctl start haveged.service

I must admit It might be worth a try.

[armakolas]

The command "sudo apt purge libpam-gnome-keyring" did nothing to LXQT , MATE and Cinnamon installations of mine, because the package was not installed. If you check the minimalcli.isos package list, you will not find it there.

After checking, via aptus > install sparky kernel, whether I could install sparky kernel, I saw something like "It is allready installed" in both lxqt and cinnamon. I am not sure if I had checked it in Mate or not before I erased the hard disk.

I will try the haveged.service now and I will post again.

[armakolas]

Success!
The absolute solution to the "taking too long after login screen to display the desktop" problem is:

Code Select Expand

sudo apt-get install haveged
sudo systemctl enable haveged.service
sudo systemctl start haveged.service

It worked perfectly! Both LXQT and Cinnamon desktop loaded the desktop immediately after login!
Thank you very much!

In addition it is proven that

Code Select Expand

sudo systemctl is a great tool that reveals much more information than "systemd-analyze". A GUI for systemctl would add even more value to it.

What is interesting is that my Sparky LXQT 32bit uses 235mb of memory when started (old intel laptop), while Sparky Cinnamon 32 bit uses only 290mb of memory when started (old intel desktop). I had never seen something so low from Cinnamon. This proves the usefulness of installing from sparky minimalcli iso.

Great solution, great linux distribution, great forum!

[paxmark1]

I did a quick read on "man haveged"     maybe it has something to do with

https://daniel-lange.com/archives/152-Openssh-taking-minutes-to-become-available,-booting-takes-half-an-hour-...-because-your-server-waits-for-a-few-bytes-of-randomness.html        ## which comes via Planet Debian.

towards the end of the web page

Haveged
apt install haveged

Haveged is a user-space daemon that gathers entropy though the timing jitter any CPU has. It will only run "late" in boot but may still get your openssh back online within seconds and not minutes.

[Bill Statler]

I'm glad I finally read this topic.  I'm using MATE, and I've been seeing some delay (like 5 to 30 seconds) before the desktop is displayed -- and if I move the mouse, the desktop pops up promptly.  Mouse motion is probably seeding the random number generator.

Also I've been wondering about the random number generator.  I've got an alarm clock script that uses 'shuf' to pick a random music file to play, and it seems like I've been hearing a lot of the same "random" tunes recently.  I haven't done a controlled test, so it might just be my misperception -- but it would be weird if both issues had the same cause.

https://daniel-lange.com/archives/152-Openssh-taking-minutes-to-become-available,-booting-takes-half-an-hour-...-because-your-server-waits-for-a-few-bytes-of-randomness.html

Thanks for that link.  I tried one of his other suggestions in place of 'haveged':

Kernel boot parameter

From kernel 4.19 (Debian Buster currently runs 4.18 [Update: but will be getting 4.19 before release according to Ben via Mika]) you can set RANDOM_TRUST_CPU at compile time or random.trust_cpu=on on the kernel command line. This will make Intel / AMD system trust RDRAND and fill the entropy pool with it.

This tells Linux to trust the CPU's built-in random number generator.  How to set it up:

• sudo nano /etc/default/grub
• Find a line that looks like this:
     GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=UUID=..."
  and change it to:
     GRUB_CMDLINE_LINUX_DEFAULT="quiet splash random.trust_cpu=on resume=UUID=..."
  and save the file (ctrl-X if you're using nano).
• sudo update-grub
• Restart the computer.

Maybe it worked.  I didn't see a delay before the desktop appeared.  (Tomorrow morning I'll see what random tune wakes me up!)