System slow on booting

[Lyubomir]

I have installed a Kubuntu 20.04.1 for my grandma, the system is slow to boot, takes between a minute 30 seconds to two minutes to display the Plasma Desktop. I am attaching a journalctl log and a systemd-bootchart img.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: xorg 1:7.7+19ubuntu14
ProcVersionSignature: Ubuntu 5.4.0-48.52-generic 5.4.60
Uname: Linux 5.4.0-48-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.20.11-0ubuntu27.9
Architecture: amd64
CasperMD5CheckResult: skip
CompositorRunning: None
Date: Wed Oct 7 15:26:27 2020
DistUpgraded: Fresh install
DistroCodename: focal
DistroVariant: ubuntu
DkmsStatus:
 bcmwl, 6.30.223.271+bdcom, 5.4.0-42-generic, x86_64: installed
 bcmwl, 6.30.223.271+bdcom, 5.4.0-48-generic, x86_64: installed
ExtraDebuggingInterest: No
GraphicsCard:
 Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display [8086:0f31] (rev 0c) (prog-if 00 [VGA controller])
   Subsystem: ASUSTeK Computer Inc. Atom Processor Z36xxx/Z37xxx Series Graphics & Display [1043:14dd]
InstallationDate: Installed on 2020-09-22 (14 days ago)
InstallationMedia: Kubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 004: ID 04f2:b404 Chicony Electronics Co., Ltd USB2.0 HD UVC WebCam
 Bus 001 Device 003: ID 04ca:2006 Lite-On Technology Corp. Broadcom BCM43142A0 Bluetooth Device
 Bus 001 Device 002: ID 1c4f:0034 SiGma Micro Usb Mouse
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: ASUSTeK COMPUTER INC. X551MA
ProcEnviron:
 LANGUAGE=ru:en_US
 TERM=xterm-256color
 PATH=(custom, no user)
 LANG=bg_BG.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-48-generic root=/dev/mapper/vgkubuntu-root ro quiet splash init=/lib/systemd/systemd-bootchart vt.handoff=7
SourcePackage: xorg
Symptom: display
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/15/2015
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: X551MA.515
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: X551MA
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: 1.0
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK COMPUTER INC.
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrX551MA.515:bd04/15/2015:svnASUSTeKCOMPUTERINC.:pnX551MA:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnX551MA:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
dmi.product.family: X
dmi.product.name: X551MA
dmi.product.sku: ASUS-NotebookSKU
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK COMPUTER INC.
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.101-2
version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.8-0ubuntu1~20.04.1
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.xserver-xorg-core: xserver-xorg-core 2:1.20.8-2ubuntu2.4
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200226-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

[Lyubomir (mystiquewolf)]

Attaching critical chain

[Lyubomir (mystiquewolf)]

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

[Lyubomir (mystiquewolf)]

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

[Lyubomir (mystiquewolf)]

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

[Daniel van Vugt (vanvugt)]

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

[Balint Reczey (rbalint)]

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.

[Lyubomir (mystiquewolf)]

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.

[Lyubomir (mystiquewolf)]

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

[Zygmunt Krynicki (zyga)]

Could you provide journal log from the last boot?

journalctl -b 0 should do the trick

[Lyubomir (mystiquewolf)]

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.

[Oliver Grawert (ogra)]

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 ?

[Lyubomir (mystiquewolf)]

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.

[Lyubomir (mystiquewolf)]

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.

[Oliver Grawert (ogra)]

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 ?

[Oliver Grawert (ogra)]

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 ...

[Lyubomir (mystiquewolf)]

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.

[Oliver Grawert (ogra)]

> 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 ;) )