~ systemd-analyze critical-chain upower.service INT ✘ 9m 57s
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
upower.service +1min 27.209s
└─basic.target @2.047s
└─sockets.target @2.047s
└─dbus.socket @2.047s
└─sysinit.target @2.046s
└─systemd-backlight@backlight:intel_backlight.service @3.841s +28ms
└─system-systemd\x2dbacklight.slice @3.841s
└─system.slice @681ms
└─-.slice @681ms
unmask this:
sudo systemctl unmask systemd-backlight@leds:kbd_backlight.service
sudo systemctl enable systemd-backlight@leds:kbd_backlight.service
open this:
sudo nano /etc/default/grub
and inside this line: GRUB_CMDLINE_LINUX_DEFAULT inside the quotes add this parameter:
systemd.restore_state=0
dont remove anything, just add it to existing parameters, save the file with ctrl+x, press ‘y’ then enter, update grub:
sudo update-grub
reboot and see …
I did it, but couldn’t notice any real change.
GRUB_DEFAULT=saved
GRUB_TIMEOUT=5
GRUB_TIMEOUT_STYLE=hidden
GRUB_DISTRIBUTOR="Manjaro"
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash apparmor=1 security=apparmor udev.log_priority=3 systemd.restore_state=0"
GRUB_CMDLINE_LINUX=""
ok, so add another parameter to the grub, just like you did above:
acpi_osi='Windows 2018'
save it, update grub and reboot…
if it didnt helped, you have to experiment with these parameters, to see if one of them helps… so replace the one that didnt work with:
acpi_osi=! acpi_osi='Windows 2018'
save grub, update grub, reboot… if it didnt work, try:
acpi_osi=! acpi_osi='Windows 2022'
save grub, update grub, reboot and see … if it doenst work post output again from:
systemd-analyze blame
Unfortunately, it didn’t help. What I find odd is that “systemd-analyze blame” still doesn’t work because the boot process hasn’t finished yet. It should be finished by now.
~ systemd-analyze blame ✔
1min 22.046s upower.service
4.983s pkgfile-update.service
4.804s plymouth-quit-wait.service
4.202s NetworkManager-wait-online.service
1.000s dev-nvme0n1p4.device
421ms systemd-udev-trigger.service
392ms systemd-remount-fs.service
373ms systemd-modules-load.service
311ms mnt-Homearchiv.mount
295ms systemd-tmpfiles-setup.service
282ms modprobe@fuse.service
262ms ufw.service
246ms modprobe@drm.service
228ms systemd-tmpfiles-setup-dev.service
217ms apparmor.service
179ms lvm2-monitor.service
163ms modprobe@loop.service
153ms plymouth-read-write.service
146ms modprobe@dm_mod.service
137ms boot-efi.mount
134ms systemd-vconsole-setup.service
106ms user@1000.service
103ms systemd-journal-flush.service
100ms systemd-random-seed.service
83ms modprobe@configfs.service
82ms kmod-static-nodes.service
69ms cups.service
66ms systemd-fsck@dev-disk-by\x2duuid-1E98\x2dE20F.service
54ms plymouth-start.service
51ms systemd-sysctl.service
50ms logrotate.service
42ms systemd-backlight@leds:kbd_backlight.service
39ms user-runtime-dir@1000.service
36ms ModemManager.service
36ms systemd-logind.service
34ms udisks2.service
33ms systemd-user-sessions.service
30ms systemd-journald.service
28ms systemd-udevd.service
26ms systemd-timesyncd.service
26ms alsa-restore.service
24ms sys-fs-fuse-connections.mount
22ms systemd-update-utmp.service
20ms sys-kernel-config.mount
19ms systemd-backlight@backlight:acpi_video0.service
19ms accounts-daemon.service
18ms teamviewerd.service
18ms NetworkManager.service
18ms bluetooth.service
18ms polkit.service
14ms bolt.service
13ms dbus.service
10ms power-profiles-daemon.service
9ms dev-hugepages.mount
8ms dev-mqueue.mount
8ms colord.service
8ms iio-sensor-proxy.service
8ms sys-kernel-debug.mount
7ms sys-kernel-tracing.mount
5ms gdm.service
5ms wpa_supplicant.service
3ms systemd-rfkill.service
3ms rtkit-daemon.service
2ms tmp.mount
lines 42-64/64 (END)
Do you have time tomorrow evening as well? I’m from Germany and it’s now after midnight for me. I have to get up early tomorrow. In any case, thank you very, very much for taking so much time to help me.
the upower takes too long…
can you disable the battery extension? if yes, reboot and see…
yes we can continue tomorrow…
So here I am again. No, I don’t know how to disable it.
I have disabled all extensions through https://extensions.gnome.org.
well im out of ideas… its the upower service… so try to disable it too:
sudo systemctl disable upower.service
sudo systemctl mask upower.service
reboot and see … if it still happens post again output from:
systemd-analyze blame
~ systemd-analyze blame ✔
4.521s plymouth-quit-wait.service
4.401s NetworkManager-wait-online.service
922ms dev-nvme0n1p4.device
386ms systemd-udev-trigger.service
366ms systemd-remount-fs.service
350ms systemd-modules-load.service
297ms mnt-Homearchiv.mount
279ms modprobe@fuse.service
250ms lvm2-monitor.service
250ms modprobe@drm.service
242ms systemd-tmpfiles-setup.service
231ms systemd-tmpfiles-setup-dev.service
231ms apparmor.service
176ms ufw.service
170ms plymouth-read-write.service
145ms systemd-journal-flush.service
130ms systemd-vconsole-setup.service
122ms systemd-timesyncd.service
121ms systemd-update-utmp.service
113ms user@120.service
102ms systemd-random-seed.service
94ms boot-efi.mount
72ms cups.service
69ms user@1000.service
66ms systemd-fsck@dev-disk-by\x2duuid-1E98\x2dE20F.service
60ms modprobe@configfs.service
60ms kmod-static-nodes.service
60ms systemd-sysctl.service
53ms systemd-backlight@backlight:acpi_video0.service
49ms modprobe@loop.service
46ms user-runtime-dir@120.service
41ms plymouth-start.service
39ms user-runtime-dir@1000.service
37ms systemd-backlight@leds:kbd_backlight.service
34ms ModemManager.service
33ms systemd-user-sessions.service
33ms alsa-restore.service
33ms systemd-udevd.service
30ms udisks2.service
28ms systemd-hostnamed.service
28ms geoclue.service
26ms fprintd.service
21ms sys-fs-fuse-connections.mount
20ms teamviewerd.service
19ms accounts-daemon.service
19ms systemd-journald.service
19ms systemd-localed.service
18ms sys-kernel-config.mount
16ms systemd-logind.service
16ms bluetooth.service
15ms polkit.service
14ms NetworkManager.service
13ms bolt.service
12ms dbus.service
10ms colord.service
9ms power-profiles-daemon.service
9ms iio-sensor-proxy.service
9ms dev-hugepages.mount
8ms dev-mqueue.mount
7ms sys-kernel-debug.mount
7ms sys-kernel-tracing.mount
6ms modprobe@dm_mod.service
6ms gdm.service
4ms wpa_supplicant.service
3ms systemd-rfkill.service
2ms rtkit-daemon.service
1ms tmp.mount
lines 45-67/67 (END)
Well, I don’t know. It’s already a bit faster than at the beginning. However, my laptop has been faster before. I am considering installing a different distribution for a certain period of time and see if my notebook runs better with it. But it’s really a shame. I have been using Manjaro for over two years now and was always very satisfied. Maybe I shouldn’t have bought this notebook. It has caused problems with Linux right from the start. Everything is simply designed for Windows.
it looks ok… post output from:
systemd-analyze
~ systemd-analyze INT ✘ 12m 49s
Startup finished in 4.627s (firmware) + 2.207s (loader) + 31.270s (kernel) + 11.689s (userspace) = 49.794s
graphical.target reached after 11.688s in userspace.
~
it still takes a lot of time to load… well i really dont know what else to try…
I have a feeling that it’s somehow related to GNOME. I think I’ll install the KDE version and see if I have the same issues there.
Anyway, thank you so much for all your effort. I can still write here and let you know if I still have the same issue with KDE or not.
I have no exact ideas but mine 6.3-rc6 kernel starts a way faster on the older and weaker CPU (i7-1195G7), KDE:
systemd-analyze
... + 7.150s (kernel) + ...
-
What if to try to switch to kernel of 6.2 and 6.3 to give them a try? Idea: may be the newer hardware, the newer kernel it should be.
-
If to filter
journalctloutput by priority to leave only higher than mentioned, it will be easier to find higher related info there:
In the boot up where you has been reached lags try to post separate excerpts of:
(do issue the sync command on a machine prior to grab logs)
journalctl -b -p2 --no-pager --no-hostname -o short-monotonic
journalctl -b -p3 --no-pager --no-hostname -o short-monotonic
journalctl -b -p4 --no-pager --no-hostname -o short-monotonic
journalctl -b -p5 --no-pager --no-hostname -o short-monotonic
-
Does (dis-) or connection of the power supply unit’s plug make influence?
-
Does any “non-recommended” options to use with Manjaro like “fast start”, “secure boot” or similar are enabled in the UEFI firmware settings?
Thank you for your help, alven.
I have already tried the kernel 6.2 as well. Unfortunately, it has the exact same problems.
I have given up on this notebook already. It is simply not suitable for Linux. I have looked on eBay and it is currently being offered for a higher price than what I paid for it new. I have just ordered a Tuxedo notebook and will be listing my LG for sale on eBay. With the Tuxedo, I know what I am getting and will not have these problems anymore.
It says 31 seconds to load kernel, this should not be related to GNOME.
My suggestion would be to try different kernels, and see if some of them don’t take 30 seconds to load, as that is asinine nowadays, it should take seconds.
To be fair, if you had this issue i must mention it, i had kernel load take a long time at most boots but not all, and found the issue was with the SSD firmware of one of the disks i DID NOT USE. So maybe take a closer look at the boot log, and see if the delay happens around hard disk initialization.
The journal gives millisecond log of what happens at boot, so you should see where the time accumulates.
Seems to be “LG” does not mean “Linux, GNU” yet 
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.