Boot waits 4 seconds after basic.target with no activity

Jujube548 · 2026-01-17 22:21:40

Hello,
I have noticed my userspace boot time always being inflated by 4 sec with some random service like logind or networkd or dbus-broker being blamed by systemd-analyze blame. When looking further into it, it always turns out that service only has like 200ms on the cpu and just waits the 4 seconds for no reason. Twice now, no service was even blamed: the verbose during boot just showed reached basic.target and hanged there for 4 seconds.

Relevant journalctl output :

Jan 17 21:10:29 archlinux systemd[1]: Started D-Bus System Message Bus.
Jan 17 21:10:29 archlinux dbus-broker-launch[343]: Ready
Jan 17 21:10:29 archlinux systemd[1]: Reached target Basic System.
Jan 17 21:10:29 archlinux systemd-networkd[232]: wlan0: Link UP
Jan 17 21:10:34 archlinux systemd[1]: Started Seat management daemon.

Full journalctl can be found at https://pastebin.com/Jw1N4AGL

Here's most of my systemd-analyze blame:

1.043s dev-nvme0n1p2.device
 936ms upower.service
 816ms systemd-udev-trigger.service
 216ms iwd.service
 202ms user@1000.service
 171ms systemd-networkd.service
 140ms boot.mount
 122ms systemd-tmpfiles-setup.service
 121ms ldconfig.service
 112ms polkit.service
  98ms systemd-tmpfiles-setup-dev-early.service
  96ms systemd-resolved.service
  96ms systemd-journald.service
  78ms systemd-journal-flush.service
  77ms dev-zram0.swap
  73ms systemd-vconsole-setup.service
  71ms systemd-logind.service
  69ms systemd-udevd.service
  69ms systemd-hostnamed.service
  61ms systemd-timesyncd.service
  59ms systemd-tmpfiles-clean.service
  49ms systemd-update-done.service
  47ms systemd-zram-setup@zram0.service
  41ms systemd-udev-load-credentials.service
  39ms systemd-tmpfiles-setup-dev.service
  39ms systemd-journal-catalog-update.service
  38ms systemd-userdbd.service
  34ms dev-hugepages.mount
  34ms dev-mqueue.mount
  33ms sys-kernel-debug.mount
  32ms dbus-broker.service
  32ms sys-kernel-tracing.mount
  31ms systemd-remount-fs.service
  31ms systemd-sysctl.service
  31ms kmod-static-nodes.service
  31ms sys-kernel-config.mount
  30ms systemd-backlight@backlight:amdgpu_bl1.service
  30ms systemd-sysusers.service
  29ms sys-fs-fuse-connections.mount
  27ms systemd-userdb-load-credentials.service
  24ms systemd-modules-load.service
  23ms rtkit-daemon.service
  22ms tmp.mount

Output of systemd-analyze plot https://imgur.com/a/pAIVKsE

Maybe important : I use booster for my initramfs generation, as it cuts my initrd+kernel time from 8s to about 1s.

Thank you for your help

Jujube548 · 2026-01-17 22:58:57

Update: after reading through https://bbs.archlinux.org/viewtopic.php?id=311403, I tried adding to the kernel parameters

module_blacklist=amdgpu

this completely removes the 4s artificial slowdown (from 6.6s userspace down to 2s)
How do I fix the issue going on with amdgpu while maintaining a graphics accelerator?

cryptearth · 2026-01-17 23:07:08

jeesh - you going for single-digit seconds
about 15 years ago i was used to several minutes booting my windows 7 (even a fresh install on back then very fast systems with high speed drives took up to a minute - depending on how driver crap had to load)
today with fast flash storage and optimized stuff i'm at my desktop within less than a minute from cold and dark (which includes several seconds of uefi post and 5 second grub timeout, about 10-15 seconds importing a zfs pool)
if you look for a "it's up and awake in seconds": don't shutdown your system - otherwise: just live with that secnds - they don't cause any issue and harm no one

Jujube548 · 2026-01-17 23:16:06

I understand and agree, and indeed my desktop has over double the boot time with Arch but I don't bother to try to cut it.
However, this is with my laptop, where shutting it down and turning it on cause me great satisfaction, and I enjoy a snappy response.

Jujube548 · 2026-01-17 23:20:39

Still the same issue

Last edited by Jujube548 (2026-01-20 17:12:29)

Jujube548 · 2026-01-20 16:37:16

Any help would be appreciated

V1del · 2026-01-20 19:05:55

Don't do that: https://wiki.archlinux.org/title/Genera … es#Bumping

You have iwd and systemd-networkd running simultaneously, is that properly configured that that's the correct setup? It's most likely some piece of HW that is considered "vital" and needs to init. Have you tried using the booster.debug kernel flag to potentially get more information on what it's doing/generally up the kernel loglevel with debug to maybe get more logs on what causes it to pause.

seth · 2026-01-21 10:01:13

Disable seatd…

Jujube548 · 2026-01-21 16:08:00

Is that really it? I‘ll try rn

Jujube548 · 2026-01-21 16:14:03

V1del wrote:

Don't do that: https://wiki.archlinux.org/title/Genera … es#Bumping

duly noted
As for systemd-networkd and iwd, I have tried disabling both and only starting them manually when needed post-boot, but the delay remained.
I am quite convinced amdgpu is the problem, as it boots almost instantly when blacklisted, at the cost of graphics acceleration not being available

Last edited by Jujube548 (2026-01-21 16:18:23)

seth · 2026-01-21 16:25:26

Afaict you don't have https://wiki.archlinux.org/title/Iwd#En … figuration so iwd+systemd-networkd is a valid combination.

There's nothing suggesting amdgpu would cause the 4s stall between

Jan 17 21:10:29 archlinux systemd-networkd[232]: wlan0: Link UP
Jan 17 21:10:34 archlinux systemd[1]: Started Seat management daemon.

but you seem to autologin into a some wayland session there seem stalls afterwards.
Do you perceive any slowdowns when not automatically starting that wayland session and after disablign seatd?

Jujube548 · 2026-01-21 16:37:52

seth wrote:

Afaict you don't have https://wiki.archlinux.org/title/Iwd#En … figuration so iwd+systemd-networkd is a valid combination.
There's nothing suggesting amdgpu would cause the 4s stall between
Jan 17 21:10:29 archlinux systemd-networkd[232]: wlan0: Link UP
Jan 17 21:10:34 archlinux systemd[1]: Started Seat management daemon.
but you seem to autologin into a some wayland session there seem stalls afterwards.
Do you perceive any slowdowns when not automatically starting that wayland session and after disablign seatd?

I just tried disabling seatd and no changes there.
About autologin, I see the same delay with it on or off.
my latest

 journalctl -b

gives the following relevant output:

Jan 21 16:27:46 archlinux systemd-logind[331]: Watching system buttons on /dev/input/event2 (Power Button)
Jan 21 16:27:46 archlinux systemd-logind[331]: Watching system buttons on /dev/input/event0 (Power Button)
Jan 21 16:27:46 archlinux systemd-logind[331]: Watching system buttons on /dev/input/event1 (Lid Switch)
Jan 21 16:27:46 archlinux systemd-logind[331]: Watching system buttons on /dev/input/event3 (AT Translated Set 2 keyboard)
Jan 21 16:27:46 archlinux systemd-logind[331]: Watching system buttons on /dev/input/event9 (HP WMI hotkeys)
Jan 21 16:27:46 archlinux systemd-logind[331]: New seat seat0.
Jan 21 16:27:46 archlinux systemd[1]: Started User Login Management.
Jan 21 16:27:50 archlinux kernel: [drm] amdgpu kernel modesetting enabled.
Jan 21 16:27:50 archlinux kernel: amdgpu: Virtual CRAT table created for CPU
Jan 21 16:27:50 archlinux kernel: amdgpu: Topology: Add CPU node
Jan 21 16:27:50 archlinux kernel: amdgpu 0000:04:00.0: enabling device (0006 -> 0007)
Jan 21 16:27:50 archlinux kernel: amdgpu 0000:04:00.0: amdgpu: initializing kernel modesetting (RAVEN 0x1002:0x15D8 0x103C:0x86FD 0xC2).
Jan 21 16:27:51 archlinux iwd[329]: Wireless daemon version 3.10
Jan 21 16:27:51 archlinux systemd[1]: Started Wireless service.

Still not sure why, but I'm convinced it's amdgpu
Thank you for the help until now.
Full journalctl -b : https://0x0.st/PPKF.txt

seth · 2026-01-21 17:07:47

Checks out since the gap is now before amdgpu modesetting - does it help to move amdgpu into the initramfs?

Jujube548 · 2026-01-21 17:26:08

seth wrote:

Checks out since the gap is now before amdgpu modesetting - does it help to move amdgpu into the initramfs?

I‘d imagine it does since mkinitcpio and dracut initramfs don‘t give me this problem(at the cost of much longer total boot time). However, looked as I have(before making this post), I didn‘t find a way to include specific drivers in the booster image.
I tried testing whether removing amdgpu drivers from the dracut image creates this 4 second space, but it was giving me an error about omit_drivers not being a valid config option (despite the guide I had read).
Any further pointers would be appreciated

seth · 2026-01-21 20:40:49

I didn‘t find a way to include specific drivers in the booster image.

https://wiki.archlinux.org/title/Mkinitcpio#MODULES - the kms hook should™ pick it up automatically.

at the cost of much longer total boot time

:weneedacolbertemoji:
Do you have a journal for that?

Jujube548 · 2026-01-21 20:48:12

seth wrote:

I didn‘t find a way to include specific drivers in the booster image.
https://wiki.archlinux.org/title/Mkinitcpio#MODULES - the kms hook should™ pick it up automatically.
at the cost of much longer total boot time
:weneedacolbertemoji:
Do you have a journal for that?

I‘m currently on my way home, I‘ll add a journal and try the kms hook as soon as I‘m home and I‘ll update. Once again, thank you so much for your continued effort to help. I greatly appreciate it.

Jujube548 · 2026-01-21 21:29:57

seth wrote:

I didn‘t find a way to include specific drivers in the booster image.
https://wiki.archlinux.org/title/Mkinitcpio#MODULES - the kms hook should™ pick it up automatically.
at the cost of much longer total boot time
:weneedacolbertemoji:
Do you have a journal for that?

Just got home. Yes my mkinitcpio conf does have the kms hook and indeed loads it during initrd: amdgpu still takes 4 seconds though, the wait is just in the initrd phase instead:

 Jan 21 21:20:49 archlinux systemd[1]: Stopped Create System Files and Directories.
Jan 21 21:20:49 archlinux systemd[1]: Stopped target Local File Systems.
Jan 21 21:20:49 archlinux systemd[1]: Stopped target Preparation for Local File Systems.
Jan 21 21:20:49 archlinux systemd[1]: systemd-udev-trigger.service: Deactivated successfully.
Jan 21 21:20:49 archlinux systemd[1]: Stopped Coldplug All udev Devices.
Jan 21 21:20:49 archlinux systemd[1]: Stopping Rule-based Manager for Device Events and Files...
Jan 21 21:20:49 archlinux systemd[1]: systemd-bsod.service: Deactivated successfully.
Jan 21 21:20:49 archlinux systemd[1]: Stopped Display Boot-Time Emergency Messages In Full Screen.
Jan 21 21:20:49 archlinux systemd[1]: initrd-cleanup.service: Deactivated successfully.
Jan 21 21:20:49 archlinux systemd[1]: Finished Cleaning Up and Shutting Down Daemons.
Jan 21 21:20:49 archlinux systemd[1]: systemd-battery-check.service: Deactivated successfully.
Jan 21 21:20:49 archlinux systemd[1]: Stopped Early Battery Level Check.
Jan 21 21:20:54 archlinux kernel: [drm] amdgpu kernel modesetting enabled.

I still haven't found a way to add hooks to the booster config though.
output of

sudo journalctl -b | curl -F 'file=@-' 0x0.st

https://0x0.st/PPmN.txt/
(this boot being with the mkinitcpio initramfs image)

Last edited by Jujube548 (2026-01-21 21:31:51)

seth · 2026-01-21 21:39:38

"amdgpu.runpm=0 amdgpu.bapm=0 amdgpu.aspm=0 pcie_aspm=off amdgpu.dpm=0", https://wiki.archlinux.org/title/Kernel_parameters - amdgpu.dpm=0 might break the boot altogether so be prepared to be able to remove that at the bootloader

And on a hunch: can you disable the TPM?

Jujube548 · 2026-01-21 22:04:26

seth wrote:

"amdgpu.runpm=0 amdgpu.bapm=0 amdgpu.aspm=0 pcie_aspm=off amdgpu.dpm=0", https://wiki.archlinux.org/title/Kernel_parameters - amdgpu.dpm=0 might break the boot altogether so be prepared to be able to remove that at the bootloader
And on a hunch: can you disable the TPM?

I've set the TPM device to hidden in the UEFI (when available I already had TPM off afaik, this was just a way to make it even more off if that makes sense.)
Booting with all those kernel parameters did break my boot. removing the dpm one did fix it.
Amdgpu 4sec delay issue persists with all kernel parameters except for dpm
Full journalctl -b (with booster): https://0x0.st/PPmy.txt
Relevant snippet:

Jan 21 21:55:02 archlinux systemd-logind[325]: New seat seat0.
Jan 21 21:55:02 archlinux systemd[1]: Started User Login Management.
Jan 21 21:55:07 archlinux kernel: [drm] amdgpu kernel modesetting enabled.
Jan 21 21:55:07 archlinux kernel: amdgpu: Virtual CRAT table created for CPU

Appreciate the effort of helping me troubleshoot
P.S. my gpu is an integrated one, not discrete. Don't think that changes anything though

Last edited by Jujube548 (2026-01-21 22:05:44)

seth · 2026-01-21 22:40:43

See whether you get the same w/ the LTS kernel - this is either an incredibly weird amdgpu bug or the HW really just takes that long to initialize…

Jujube548 · 2026-01-21 22:58:19

seth wrote:

See whether you get the same w/ the LTS kernel - this is either an incredibly weird amdgpu bug or the HW really just takes that long to initialize…

I did try the LTS kernel but didn’t manage to boot with it…
I’ll try again now, following the correct steps

Jujube548 · 2026-01-21 23:14:00

seth wrote:

See whether you get the same w/ the LTS kernel - this is either an incredibly weird amdgpu bug or the HW really just takes that long to initialize…

just installed the LTS kernel and booted with it (confirmed by fastfetch i'm on the LTS kernel).
Booster didn't manage to boot with it for some reason, but the mkinitcpio initramfs img did...
Still the same 4s slowdown during initrd...

Jan 21 23:09:03 archlinux systemd[1]: systemd-battery-check.service: Deactivated successfully.
Jan 21 23:09:03 archlinux systemd[1]: Stopped Early Battery Level Check.
Jan 21 23:09:07 archlinux kernel: [drm] amdgpu kernel modesetting enabled.

full journalctl -b: https://0x0.st/PPap.txt
My iGPU (and only GPU) is an AMD Radeon Vega 8 on the Ryzen 5 3500u chip.
Could it really be a bug? I'd imagine it would have been flagged by someone years before I did

Last edited by Jujube548 (2026-01-21 23:22:02)

seth · 2026-01-22 09:46:40

You could test the behavior w/ various life systems to get different kernels and userspace stacks (eg. the install isos of various distros, grml, knoppix, …)
If they all come back w/ the 4s break it's exceedingly likely a peculiarity of your HW

cryptearth · 2026-01-22 11:00:43

HP Laptop 15s-eq0xxx/86FD, BIOS F.52 09/22/2021

btw: would been cool to have that mentioned at the top of the OP
so this system has only one gpu at all?
could be a possible reason - both for the issue and noone else encountered it yet

Jujube548 · 2026-01-22 11:33:45

cryptearth wrote:

HP Laptop 15s-eq0xxx/86FD, BIOS F.52 09/22/2021
btw: would been cool to have that mentioned at the top of the OP
so this system has only one gpu at all?
could be a possible reason - both for the issue and noone else encountered it yet

Yes sorry, I was convinced it was a software issue. That said, I doubt having only an iGPU is that exceedingly rare…
This close to buying a Thinkpad T470s and be done with it (that runs an intel cpu and igpu) on my local marketplace for some 100€

Arch Linux

#1 2026-01-17 22:21:40

Boot waits 4 seconds after basic.target with no activity

#2 2026-01-17 22:58:57

Re: Boot waits 4 seconds after basic.target with no activity

#3 2026-01-17 23:07:08

Re: Boot waits 4 seconds after basic.target with no activity

#4 2026-01-17 23:16:06

Re: Boot waits 4 seconds after basic.target with no activity

#5 2026-01-17 23:20:39

Re: Boot waits 4 seconds after basic.target with no activity

#6 2026-01-20 16:37:16

Re: Boot waits 4 seconds after basic.target with no activity

#7 2026-01-20 19:05:55

Re: Boot waits 4 seconds after basic.target with no activity

#8 2026-01-21 10:01:13

Re: Boot waits 4 seconds after basic.target with no activity

#9 2026-01-21 16:08:00

Re: Boot waits 4 seconds after basic.target with no activity

#10 2026-01-21 16:14:03

Re: Boot waits 4 seconds after basic.target with no activity

#11 2026-01-21 16:25:26

Re: Boot waits 4 seconds after basic.target with no activity

#12 2026-01-21 16:37:52

Re: Boot waits 4 seconds after basic.target with no activity

#13 2026-01-21 17:07:47

Re: Boot waits 4 seconds after basic.target with no activity

#14 2026-01-21 17:26:08

Re: Boot waits 4 seconds after basic.target with no activity

#15 2026-01-21 20:40:49

Re: Boot waits 4 seconds after basic.target with no activity

#16 2026-01-21 20:48:12

Re: Boot waits 4 seconds after basic.target with no activity

#17 2026-01-21 21:29:57

Re: Boot waits 4 seconds after basic.target with no activity

#18 2026-01-21 21:39:38

Re: Boot waits 4 seconds after basic.target with no activity

#19 2026-01-21 22:04:26

Re: Boot waits 4 seconds after basic.target with no activity

#20 2026-01-21 22:40:43

Re: Boot waits 4 seconds after basic.target with no activity

#21 2026-01-21 22:58:19

Re: Boot waits 4 seconds after basic.target with no activity

#22 2026-01-21 23:14:00

Re: Boot waits 4 seconds after basic.target with no activity

#23 2026-01-22 09:46:40

Re: Boot waits 4 seconds after basic.target with no activity

#24 2026-01-22 11:00:43

Re: Boot waits 4 seconds after basic.target with no activity

#25 2026-01-22 11:33:45

Re: Boot waits 4 seconds after basic.target with no activity

Board footer