Start-up Issues

[Shaggy1444]

What Happened?

This happens when starting-up laptop on battery power (94%).

1. after the encrypted disk signon start-up takes too long (>30 secs)
2. at the OS signon screen the password typed does not show in the window

Steps to Reproduce

-just have to wait until the boot finally takes place and the signon is accepted before the desktop is displayed
-note that this behaviour also occurred using Ubuntu Jammy on this same laptop, hence the switchover to Elementary OS
-but it looks as if this may be a deeper issue related to when the laptop is running on battery power

Expected Behavior

-Linux boot from encrypted disk password to signon screen should not take more than 30 secs even on battery power
-entering an OS password to log into the system should have been displayed in the login window

OS Version

8.x (Circe)

Session Type

Classic Session (X11, This is the default)

Software Version

Latest release (I have run all updates)

Log Output

No response

[teamcons]

Hello
Please open one issue report per issue - Else it is an absolute mess to track, for both devs and other people who may complement with information.

For the first one, you can see a list of all start up processes and how long they take, by running in a terminal:

systemd-analyze blame

you may get a clue at what is causing significant startup delay. That information would be helpful for that specific issue

[Shaggy1444]

ran << systemd-analyze time >> and these are the results:

On Battery:
Startup finished in 3.514s (firmware) + 2.907s (loader) + 12.983s (kernel) + 29.862s (userspace) = 49.266s
graphical.target reached after 29.845s in userspace.

On Power:
Startup finished in 3.550s (firmware) + 2.906s (loader) + 11.435s (kernel) + 15.682s (userspace) = 33.575s
graphical.target reached after 15.658s in userspace.

so why would running on battery be slower?

this is the same issue with Ubuntu Jammy which led me to Elementary OS. not sure whether others are having same issue with other distros.

[Shaggy1444]

dug a little further with:

<< systemd-analyze critical-chain >>
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.

graphical.target @15.658s
└─multi-user.target @15.658s
└─wazuh-agent.service @9.444s +6.213s
└─network-online.target @9.428s
└─NetworkManager-wait-online.service @3.442s +5.985s
└─NetworkManager.service @2.238s +1.188s
└─dbus.service @2.091s +131ms
└─basic.target @2.083s
└─sockets.target @2.083s
└─clamav-daemon.socket @2.071s +11ms
└─sysinit.target @2.067s
└─systemd-backlight@backlight:intel_backlight.service @3.196s +35ms
└─system-systemd\x2dbacklight.slice @3.181s
└─system.slice @691ms
└─-.slice @690ms

took notice of the network-online.target which impacted the wazuh-agent.service.
checked system log for errors.
a lot of errors being generated and related to this device (wireless adapter):
+-1d.6-[07]----00.0 Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter

also,
pipewire[2130]: mod.jackdbus-detect: Failed to receive jackdbus reply: org.freedesktop.DBus.Error.ServiceUnknown: The name org.jackaudio.service was not provided by any .service files
wireplumber[2133]: Failed to get percentage from UPower: org.freedesktop.DBus.Error.NameHasNoOwner
wireplumber[2133]: WpPortalPermissionStorePlugin:0x6542000c98b0 Failed to call Lookup: GDBus.Error:org.freedesktop.portal.Error.NotFound: No entry for camera

only thought is potential driver issue for the Atheros wireless adapter, will hunt for any updates.
have no clue about pipewire/wireplumber error messages.

seems similar issues on ubuntu and mint flavours.

[Shaggy1444]

Avoided loading the Atheros wireless adapter drivers, will wait until new firmware updates are applied by distro.

When on battery power, and after initial OS signon, not encrypted disk signon, starting any app is rather slow - anywhere between 10-20 seconds.

Sometimes starting a few apps one after the other causes a system hang and only way to recover is force power-off.

Not seeing this happen when running on power, but will report if it does.