System slow on booting

Attaching critical chain

Startup finished in 7.329s (kernel) + 55.638s (userspace) = 1min 2.967s
graphical.target reached after 53.979s in userspace

I've also ran a stopwatch with the phone:
The KDE Plasma logo and spinner appeared at 1m 37 seconds
the KDE logo disappeared and the desktop was shown at 1m 57 seconds
The desktop loaded its taskbar and iconds/etc everything at 2m 19 seconds

I'm not that big fan of Windows, but i'm pretty sure her Windows was booting for under a minute.

Again I can't figure this out, sorry. But it looks like systemd or snapd people might have some idea.

I'm not sure what the expectation is here. This is a slow laptop with a spinning disk and 4G RAM. The critical chain shows that waiting for network adds quite some time. Also teamviewer is installed adding +5s.

I am not a Windows fanboy, but the system is booting much slower than Windows was before. So i think it is a bug and uploaded the logs in hope to see what causes the slowdown and how it can be improved. That was the expectation. Also, why network has to come online for me to be able to login? Why is it even waiting for it? It should not be blocking login i believe.

As this bug is set to incomplete, is there any other information that i need to provide?

Could you provide journal log from the last boot?

journalctl -b 0 should do the trick

Providing...

P.S.: This bug is not supposed to be acted up on ASAP, but it would be nice to be kept here as a notice that the boot is slow and needs to be taken into account for future work. That's in my opinion.

erm ...

this is an atom/celeron laptop with 4GB that starts BOINC as a system service during boot ?

there seems to also be a lot of broken gnome-shell extensions installed on this system that error out during startup ...

there is ifupdown installed which is probably involved with the network manager slowness (was this an upgrade from a former LTS ? (ifupdown is deprecated since years now and should not be installed at all) ...

have you ever tried a plain unmodified 20.04.1 on this machine without installing all this extra software on top ?

This is an official Kubuntu 20.04 LTS installed from ISO because Windows has broken so much that even the recovery options were broken.

Nevertheless, Windows was booting much faster on this very same laptop, likely because of the "fast boot" feature. It was booting in under a minute, I'm pretty sure of this even if i haven't used a stopwatch. The reality is that 2 and a half minutes is way too much compared to one minute at worst.

Oh, excuse me. Just realised that you mentioned BOINC. I'm very sorry, but i have uploaded the wrong file. This one is from my Acer Aspire, not from the grandma's laptop. I'm sorry again, i've created that journal.txt due to another issue and both files were named that way. My PC is an upgrade, yes.

I'm attaching her journal.txt now.

okay, thats quite different ...

a) you run the lowlatency kernel for whatever reason ... this is clearly the worst choice you can pick for already slow hardware (low latency -> do one thing as fast as you can ... ignore other things ... i.e. you trade overall system performance for the ability to do one single task very fast (a typical use for this kernel is fully reliable professional audio processing (no crackling, no jitter) at the cost of desktop performance)

b) the (third party) wlan driver crashes in a loop, preventing the network from coming up for quite some time ...

c) you seem to run dnscrypt-proxy and that seems to effectively delay working DNS resolution until the end of the boot for whatever reason ...

same question as before ... have you tired running a completely unmodified install of 20.04.1 on this hardware ? did that behave similarly slow ?

oh, and i missed, d) there is a mis-configured postfix install running on that device too ... since it is not configured and crashing in a loop during boot anyway, i'd recomend removing postfix ...

a) On theory it compromises the throughput (the whole CPU time that will take for a process to finish will be longer) for better responsiveness, even under high load. So mouse clicks/UI events should be handled faster and say, when decompressing large files or other CPU load by specific process the user interface should not freeze.

b) I'll have to look at this and maybe report a bug somewhere. I should really get used to checking the logs more frequently.

c) I'll also have to investigate this, but maybe it's because i have overridden the DNS address to be used from the default one and dnscrypt-proxy hasn't started yet, plus systemd-resolved listening on a different port than the used one.

d) I have removed it, thanks!

I can't speak with the numbers, it might have been a little bit faster, but it was noticeably slower than Windows.

> a) On theory it compromises the throughput (the whole CPU time that will take for a
> process to finish will be longer) for better responsiveness, even under high load. So
> mouse clicks/UI events should be handled faster and say, when decompressing large files
> or other CPU load by specific process the user interface should not freeze.

err, nope ... it will prioritize processes differently (the preemption model is completely different) and is not actually optimized for desktop style performance, i'd really go back to the generic kernel here (we'd ship the lowlatency kernel by default on the desktop images if it would actually behave like you describe ;) )