Everything from boot to loading the desktop takes extra time

Hi, i am dual-booting Windows with Manjaro, using the 6.12 kernel & XFCE
I am new to this operating system but i am enjoying it a lot so i thank everyone who made it, but i have just 1 problem

My last boot time was a solid 1min 3.224s, and after i enter my password and login from the login screen, it takes about 30 seconds until my desktop is fully functional. the panel takes about 10 seconds to appear fully and another 20 until my desktop and icons load, until my background changes from what was used in the login screen, which i feel is somehow connected to the boot time

I think it is worth mentioning, that in order for me to install manjaro in the first place, i had to scramble for about 30 hours since im a newbie and only got it to boot (properly) after finding out i have to use “pci=noacpi”
Without it the system could also boot but i couldnt use my mouse or internet and the boot was still slow, so the boot parameter probably is insignificant

All applications take time to load on first launch, for example Firefox taking 10s to start, but from that point on it opens normally

here are outputs from systemd-analyze and systemd-analyze blame

20.210s plocate-updatedb.service
12.713s snapd.service
12.569s dev-sda1.device
 8.990s ModemManager.service
 6.919s NetworkManager.service
 5.990s systemd-journal-flush.service
 5.118s systemd-tmpfiles-setup.service
 3.917s udisks2.service
 3.652s cups.service
 3.648s apparmor.service
 3.512s systemd-udevd.service
 2.794s systemd-tmpfiles-setup-dev-early.service
 2.479s upower.service
 2.266s colord.service
 1.830s polkit.service
 1.776s wpa_supplicant.service
 1.731s lvm2-monitor.service
 1.683s lightdm.service
 1.424s bluetooth.service
 1.401s avahi-daemon.service
 1.314s systemd-random-seed.service
 1.288s dbus-broker.service
 1.194s accounts-daemon.service
 1.018s plymouth-start.service
  956ms systemd-journald.service
  815ms snapd.apparmor.service
  776ms ufw.service
  719ms systemd-rfkill.service
  661ms plymouth-read-write.service
  635ms systemd-logind.service
  566ms systemd-modules-load.service
  563ms systemd-udev-load-credentials.service
  562ms systemd-udev-trigger.service
  484ms systemd-sysctl.service
  441ms systemd-user-sessions.service
  422ms user@1000.service
  371ms systemd-timesyncd.service
  367ms dev-hugepages.mount
  365ms dev-mqueue.mount
  365ms systemd-update-utmp.service
  364ms sys-kernel-debug.mount
  363ms sys-kernel-tracing.mount
  351ms logrotate.service
  351ms tmp.mount
  348ms kmod-static-nodes.service
  347ms modprobe@fuse.service
  346ms modprobe@drm.service
  346ms modprobe@configfs.service
  316ms systemd-tmpfiles-clean.service
  176ms systemd-userdbd.service
  155ms rtkit-daemon.service
  117ms systemd-hostnamed.service
  104ms systemd-remount-fs.service
  101ms systemd-vconsole-setup.service
   59ms systemd-tmpfiles-setup-dev.service
   47ms plymouth-quit-wait.service
   46ms plymouth-quit.service
   41ms proc-sys-fs-binfmt_misc.mount
   36ms snapd.socket
   30ms user-runtime-dir@1000.service
   30ms modprobe@dm_mod.service
   29ms modprobe@loop.service
   24ms alsa-restore.service
    9ms sys-fs-fuse-connections.mount
    8ms sys-kernel-config.mount
Startup finished in 12.369s (firmware) + 7.149s (loader) + 8.950s (kernel) + 34.755s (userspace) = 1min 3.224s 
graphical.target reached after 34.754s in userspace.

im guessing graphical.target is the desktop loading?
i have already looked through a bunch of topics before posting but nothing was helpful, so if anybody can help then thanks!!

totally normal and even on the fast side if you are using spinning disks

doesn’t run immediately, as far as I know - or only the first time
it starts a timer which then starts the job … later

this could potentially be eliminated if you don’t need it

it won’t save you 9 seconds though …

These things run in parallel - not one on top of each other.

Totally normal when I see the timings here:

I would expect a spinning disk here (otherwise it would 1-5sec) which is slow and the bottle neck here.

You can switch scheduler to bfq for example, which is more cpu intensive, but also more responsive.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.