Slow boot on fresh Arch Linux installation

SevenStart · 2025-01-19 18:57:02

Hi Arch Community,

I’m encountering frustratingly long boot times (50–70 seconds) despite having a fresh installation on brand-new hardware. My PC was built just three days ago, specifically optimized for Linux, with high-end components.
For comparison, a test installation of Windows 10 on the same system resulted in boot times of just 10–15 seconds. I am puzzled as to why Arch Linux takes so long to boot.

Observed Behavior

The system boots up to the GDM greeter in about 10–24 seconds. After entering my password, there’s a 30-second delay before the GNOME shell loads. On Xorg, this delay is accompanied by a black screen.
The login process consistently waits for the CPU cooler fans to momentarily spin up louder. Once this happens, the system immediately logs in, and the GNOME shell loads without further delay.
Alternatively, if I wait approximately 30 seconds at the GDM greeter (until the CPU fans spin up), I can then enter my password and reach the GNOME shell within 3–5 seconds.

I’ve thoroughly searched various forums, support pages, and even Reddit threads, but none of the suggestions I found have resolved the issue. Many of the posts were older, and in some cases, the proposed fixes caused additional problems.

That’s why I’m reaching out to you all, hoping someone here might have insights or suggestions to help resolve this problem.

System Details

Hardware

Mainboard: ASUS ROG STRIX B650E-F GAMING WIFI (AMD AM5 Socket)
CPU: AMD Ryzen 7 9800X3D (16) @ 5.27 GHz
GPU 1: AMD Radeon RX 7900 XTX [Discrete]
GPU 1: AMD Radeon Graphics [Integrated]
Memory: 4x Corsair DDR5 6400 MHz, 32GB each (123.49 GiB total)
Swap on zram: 4.00 GiB
Disk 1 (nvme) Samsung 990 PRO (4TB, PCIe 4.0) [root] (FAT, BTRFS)
Disk 2 (nvme) Samsung 990 PRO (4TB, PCIe 4.0) [/media/data] (EXT4)
PSU: NZXT C1200 Gold ATX 3.1 (1200W)
AIO: NZXT Kraken Elite 360 RGB - V.2024

Software

OS: Arch Linux x86_64
Kernel: Linux 6.12.9-arch1-1
DE: Gnome 47.3
WM: Mutter (Wayland)
Greeter: GDM
Packages: 1138 (pacman), 20 (flatpak)
Boot System: systemd-boot (Unified Kernel Image)

UEFI - Settings

Secure Boot: enabled (signed with sbctl)
TPM: enabled (Version 1.3)

Logs and Diagnostics

Startup Time

$ systemd-analyze time

Startup finished in 14.489s (firmware) + 3.530s (loader) + 2.620s (kernel) + 4.418s (initrd) + 27.730s (userspace) = 52.790s 
graphical.target reached after 27.730s in userspace.

Service Analysis

$ systemd-analyze blame

25.317s upower.service
 4.692s dev-tpmrm0.device
 4.692s sys-devices-LNXSYSTM:00-LNXSYBUS:00-MSFT0101:00-tpmrm-tpmrm0.device
 4.691s sys-devices-platform-serial8250-serial8250:0-serial8250:0.2-tty-ttyS2.device
 4.691s dev-ttyS2.device
 4.691s sys-devices-platform-serial8250-serial8250:0-serial8250:0.3-tty-ttyS3.device
 4.691s dev-ttyS3.device
 4.690s dev-ttyS1.device
 4.690s sys-devices-platform-serial8250-serial8250:0-serial8250:0.1-tty-ttyS1.device
 4.690s sys-devices-platform-serial8250-serial8250:0-serial8250:0.0-tty-ttyS0.device
 4.690s dev-ttyS0.device
 4.686s sys-module-fuse.device
 4.686s sys-module-configfs.device
 4.674s dev-nvme1n1p1.device
 4.674s dev-disk-by\x2ddiskseq-1\x2dpart1.device
 4.674s sys-devices-pci0000:00-0000:00:02.2-0000:0e:00.0-nvme-nvme1-nvme1n1-nvme1n1p1.device
 4.674s dev-disk-by\x2dpath-pci\x2d0000:0e:00.0\x2dnvme\x2d1\x2dpart-by\x2duuid-9e3f2261\x2dac00\x2d42bf\x2d8cc0\x2dbb1dab6e5174.device
 4.674s dev-disk-by\x2dpath-pci\x2d0000:0e:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartuuid-872d880a\x2dd1fb\x2d4ee3\x2d9087\x2d9f5d01d0f187.device
 4.674s dev-disk-by\x2duuid-9e3f2261\x2dac00\x2d42bf\x2d8cc0\x2dbb1dab6e5174.device
 4.674s dev-disk-by\x2did-nvme\x2deui.0025384b41b26509\x2dpart1.device
 4.674s dev-disk-by\x2dpath-pci\x2d0000:0e:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartnum-1.device
 4.674s dev-disk-by\x2did-nvme\x2dSamsung_SSD_990_PRO_4TB_S7DPNF0XB10966V\x2dpart1.device
 4.674s dev-disk-by\x2dpartuuid-872d880a\x2dd1fb\x2d4ee3\x2d9087\x2d9f5d01d0f187.device
 4.674s dev-disk-by\x2dpath-pci\x2d0000:0e:00.0\x2dnvme\x2d1\x2dpart-by\x2dlabel-Data.device
 4.674s dev-disk-by\x2dlabel-Data.device
 4.674s dev-disk-by\x2did-nvme\x2dSamsung_SSD_990_PRO_4TB_S7DPNF0XB10966V_1\x2dpart1.device
 4.674s dev-disk-by\x2dpath-pci\x2d0000:0e:00.0\x2dnvme\x2d1\x2dpart1.device
 4.670s dev-disk-by\x2dpath-pci\x2d0000:0e:00.0\x2dnvme\x2d1.device
 4.670s sys-devices-pci0000:00-0000:00:02.2-0000:0e:00.0-nvme-nvme1-nvme1n1.device
 4.670s dev-disk-by\x2did-nvme\x2dSamsung_SSD_990_PRO_4TB_S7DPNF0XB10966V_1.device
 4.670s dev-disk-by\x2did-nvme\x2deui.0025384b41b26509.device
 4.670s dev-disk-by\x2did-nvme\x2dSamsung_SSD_990_PRO_4TB_S7DPNF0XB10966V.device
 4.670s dev-nvme1n1.device
 4.670s dev-disk-by\x2ddiskseq-1.device
 4.660s dev-nvme0n1p1.device
 4.660s dev-disk-by\x2dpartuuid-185bc6c0\x2d8ad2\x2d44bb\x2db57b\x2d2bc4a0641f63.device
 4.660s sys-devices-pci0000:00-0000:00:01.2-0000:04:00.0-nvme-nvme0-nvme0n1-nvme0n1p1.device
 4.660s dev-disk-by\x2dpath-pci\x2d0000:04:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartnum-1.device
 4.660s dev-disk-by\x2dpath-pci\x2d0000:04:00.0\x2dnvme\x2d1\x2dpart-by\x2duuid-4274\x2d714B.device
 4.660s dev-disk-by\x2did-nvme\x2deui.0025384b41b2652f\x2dpart1.device
 4.660s dev-disk-by\x2duuid-4274\x2d714B.device
 4.660s dev-disk-by\x2dpath-pci\x2d0000:04:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartuuid-185bc6c0\x2d8ad2\x2d44bb\x2db57b\x2d2bc4a0641f63.device
 4.660s dev-disk-by\x2did-nvme\x2dSamsung_SSD_990_PRO_4TB_S7DPNF0XB10974Y_1\x2dpart1.device
 4.660s dev-disk-by\x2did-nvme\x2dSamsung_SSD_990_PRO_4TB_S7DPNF0XB10974Y\x2dpart1.device
 4.660s dev-disk-by\x2ddiskseq-2\x2dpart1.device
 4.660s dev-disk-by\x2dpath-pci\x2d0000:04:00.0\x2dnvme\x2d1\x2dpart1.device
 4.659s sys-devices-pci0000:00-0000:00:01.2-0000:04:00.0-nvme-nvme0-nvme0n1-nvme0n1p2.device
 4.659s dev-disk-by\x2dpath-pci\x2d0000:04:00.0\x2dnvme\x2d1\x2dpart-by\x2duuid-6d180342\x2d41bd\x2d4dc4\x2db166\x2dc9b4baeba098.device
 4.659s dev-disk-by\x2ddiskseq-2\x2dpart2.device
 4.659s dev-nvme0n1p2.device
 4.659s dev-disk-by\x2dpartuuid-5a981c68\x2d0507\x2d414f\x2d8c90\x2dfd6dc4390c9d.device
 4.659s dev-disk-by\x2did-nvme\x2deui.0025384b41b2652f\x2dpart2.device
 4.659s dev-disk-by\x2did-nvme\x2dSamsung_SSD_990_PRO_4TB_S7DPNF0XB10974Y_1\x2dpart2.device
 4.659s dev-disk-by\x2dpath-pci\x2d0000:04:00.0\x2dnvme\x2d1\x2dpart2.device
 4.659s dev-gpt\x2dauto\x2droot.device
 4.659s dev-disk-by\x2dpath-pci\x2d0000:04:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartnum-2.device
 4.659s dev-disk-by\x2duuid-6d180342\x2d41bd\x2d4dc4\x2db166\x2dc9b4baeba098.device
 4.659s dev-disk-by\x2dpath-pci\x2d0000:04:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartuuid-5a981c68\x2d0507\x2d414f\x2d8c90\x2dfd6dc4390c9d.device
 4.659s dev-disk-by\x2did-nvme\x2dSamsung_SSD_990_PRO_4TB_S7DPNF0XB10974Y\x2dpart2.device
 4.658s dev-disk-by\x2did-nvme\x2dSamsung_SSD_990_PRO_4TB_S7DPNF0XB10974Y.device
 4.658s dev-disk-by\x2did-nvme\x2deui.0025384b41b2652f.device
 4.658s dev-disk-by\x2ddiskseq-2.device
 4.658s dev-disk-by\x2dpath-pci\x2d0000:04:00.0\x2dnvme\x2d1.device
 4.658s dev-nvme0n1.device
 4.658s dev-disk-by\x2did-nvme\x2dSamsung_SSD_990_PRO_4TB_S7DPNF0XB10974Y_1.device
 4.658s sys-devices-pci0000:00-0000:00:01.2-0000:04:00.0-nvme-nvme0-nvme0n1.device
 1.753s plymouth-quit-wait.service
  975ms systemd-binfmt.service
  764ms NetworkManager.service
  506ms ldconfig.service
  504ms fwupd.service
  384ms initrd-switch-root.service
  272ms plymouth-read-write.service
  157ms media-data.mount
  133ms systemd-tpm2-setup-early.service
  123ms systemd-pcrmachine.service
   77ms systemd-pcrphase-sysinit.service
   76ms systemd-tpm2-setup.service
   75ms systemd-pcrphase.service
   68ms systemd-pcrphase-initrd.service
   64ms bluetooth.service
   63ms systemd-journald.service
   61ms passim.service
   61ms boot.mount
   58ms systemd-hostnamed.service
   58ms colord.service
   58ms avahi-daemon.service
   57ms user@1000.service
   55ms udisks2.service
   55ms dev-hugepages.mount
   55ms dev-mqueue.mount
   54ms sys-kernel-debug.mount
   54ms sys-kernel-tracing.mount
   54ms kmod-static-nodes.service
   53ms home.mount
   53ms \x2esnapshots.mount
   53ms user-runtime-dir@1000.service
   52ms var-cache-pacman-pkg.mount
   51ms tmp.mount
   51ms rtkit-daemon.service
   50ms systemd-rfkill.service
   48ms initrd-cleanup.service
   47ms systemd-udev-trigger.service
   46ms systemd-update-done.service
   46ms wpa_supplicant.service
   45ms systemd-tmpfiles-clean.service
   36ms proc-sys-fs-binfmt_misc.mount
   30ms systemd-fsck-root.service
   28ms systemd-journal-flush.service
   27ms plymouth-switch-root.service
   22ms systemd-sysusers.service
   22ms initrd-parse-etc.service
   20ms systemd-logind.service
   19ms systemd-tmpfiles-setup-dev-early.service
   19ms polkit.service
   18ms systemd-tmpfiles-setup.service
   18ms systemd-udevd.service
   17ms geoclue.service
   16ms accounts-daemon.service
   14ms systemd-boot-random-seed.service
   13ms plymouth-start.service
   13ms dev-zram0.swap
   12ms systemd-timesyncd.service
   11ms systemd-random-seed.service
    8ms systemd-remount-fs.service
    8ms systemd-userdbd.service
    8ms systemd-zram-setup@zram0.service
    7ms systemd-journal-catalog-update.service
    7ms systemd-tmpfiles-setup-dev.service
    7ms cups.service
    7ms dbus-broker.service
    5ms systemd-modules-load.service
    5ms modprobe@drm.service
    4ms gdm.service
    4ms systemd-vconsole-setup.service
    4ms initrd-udevadm-cleanup-db.service
    4ms systemd-update-utmp.service
    3ms systemd-udev-load-credentials.service
    3ms modprobe@configfs.service
    3ms systemd-sysctl.service
    3ms systemd-user-sessions.service
    2ms modprobe@fuse.service
    2ms var-log.mount
    2ms modprobe@dm_mod.service
    1ms modprobe@loop.service
    1ms sys-kernel-config.mount
    1ms sys-fs-fuse-connections.mount

Fstab Configuration

$ cat /etc/fstab 
# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>
# /dev/nvme0n1p2
UUID=6d180342-41bd-4dc4-b166-c9b4baeba098	/         	btrfs     	rw,relatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvol=/@	0 0

# /dev/nvme0n1p2
UUID=6d180342-41bd-4dc4-b166-c9b4baeba098	/home     	btrfs     	rw,relatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvol=/@home	0 0

# /dev/nvme0n1p2
UUID=6d180342-41bd-4dc4-b166-c9b4baeba098	/var/log  	btrfs     	rw,relatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvol=/@log	0 0

# /dev/nvme0n1p2
UUID=6d180342-41bd-4dc4-b166-c9b4baeba098	/var/cache/pacman/pkg	btrfs     	rw,relatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvol=/@pkg0 0

# /dev/nvme0n1p2
UUID=6d180342-41bd-4dc4-b166-c9b4baeba098	/.snapshots	btrfs     	rw,relatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvol=/@.snapshots	0 0

# /dev/nvme0n1p1
UUID=4274-714B      	/boot     	vfat      	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro	0 2

UUID=9e3f2261-ac00-42bf-8cc0-bb1dab6e5174 /media/data auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=Data 0 0

Detailed Logs

For further details, I’ve uploaded the complete journalctl log here:
https://0x0.st/8HB2.txt

What I've Tried

Masked upower.service and liquidctl.service
Removed /media/data from /etc/fstab

Adjusted mkinitcpio.conf hooks from:

HOOKS=(base udev plymouth autodetect microcode modconf kms keyboard keymap consolefont block filesystems fsck)

To:

HOOKS=(base systemd plymouth autodetect microcode modconf kms keyboard sd-vconsole block filesystems fsck)

Disabled tpm and secure boot (which worsened boot time).
Disabled all GNOME extensions.
Disabled systemd-resolved.service
Switched between Xorg and Wayland sessions.
Updated all packages.
Reinstalled all Drives.
Reinstall Arch Linux.

Boot Parameters

cat /etc/kernel/cmdline 
root=PARTUUID=5a981c68-0507-414f-8c90-fd6dc4390c9d zswap.enabled=0 rootflags=subvol=@ rw rootfstype=btrfs quiet splash vt.global_cursor_default=0 plymouth.ignore-serial-consoles

Driver Details

$ pacman -Q | grep -i amd
amd-ucode 20250109.7673dffd-1

$ lsmod | grep amdgpu
amdgpu              15421440  90
crc16                  12288  3 bluetooth,amdgpu,ext4
amdxcp                 12288  1 amdgpu
i2c_algo_bit           20480  1 amdgpu
drm_ttm_helper         16384  1 amdgpu
ttm                   106496  2 amdgpu,drm_ttm_helper
drm_exec               12288  1 amdgpu
gpu_sched              65536  1 amdgpu
drm_suballoc_helper    12288  1 amdgpu
drm_buddy              24576  1 amdgpu
drm_display_helper    270336  1 amdgpu
video                  81920  3 asus_wmi,amdgpu,asus_nb_wmi

$ modinfo amdgpu | grep version
srcversion:     A07A2DF3BB48F7F460497CC
parm:           hws_gws_support:Assume MEC2 FW supports GWS barriers (false = rely on FW version check (Default), true = force supported) (bool)

Additional Notes

I’m concerned because this system was specifically built for Linux, and I didn’t expect these issues with fresh hardware and a new installation.
Please let me know if I’ve provided too much or too little information. I’m open to sharing additional logs or making changes as needed.

Thank you so much for your time and help!

Last edited by SevenStart (2025-01-21 09:13:10)

Awebb · 2025-01-20 19:25:00

Try without plymouth. You're spending half a minute in initrd. Perhaps something is wrong with your UKI setup.

SevenStart · 2025-01-20 21:18:26

Thank you for your suggestion! I appreciate the input.

I had already tried disabling Plymouth before, but to be thorough, I went ahead and completely uninstalled it from my system just now to confirm. Unfortunately, this didn’t make any difference, the issue persists.
As for the Unified Kernel Image (UKI), I’m not entirely sure how to verify its setup beyond checking the /etc/kernel/cmdline file, and everything there seems to look fine.
If you have any specific steps or recommendations on how I could better troubleshoot the UKI setup, I’d be happy to try them.

$ systemd-analyze time

Startup finished in 12.478s (firmware) + 2.606s (loader) + 1.926s (kernel) + 6.471s (initrd) + 27.784s (userspace) = 51.267s 
graphical.target reached after 27.784s in userspace.

$ 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 @27.784s
└─upower.service @2.430s +25.353s
  └─basic.target @2.383s
    └─systemd-pcrphase-sysinit.service @2.302s +80ms
      └─sysinit.target @2.299s
        └─systemd-binfmt.service @1.303s +996ms
          └─proc-sys-fs-binfmt_misc.mount @2.258s +38ms
            └─proc-sys-fs-binfmt_misc.automount @259ms

jl2 · 2025-01-21 09:05:39

No the point is you should now be able to see the console output and see where it hangs.
Also remove quiet, loglevel, splash, and plymouth kernel parameters.

~~Can we have a journal output?~~my bad didn't see.

For the UKI, see https://wiki.archlinux.org/title/Unified_kernel_image

Last edited by jl2 (2025-01-21 09:08:32)

twelveeighty · 2025-01-21 16:26:23

Your boot sequence is blocking/waiting for bluetooth - this might actually be your longest wait - try disabling bluetooth and see if that speeds things up:

Jan 19 18:05:20 Emres-PC kernel: Bluetooth: hci0: Device setup in 20454346 usecs

Also look into the following issues:

Jan 19 18:04:54 archlinux kernel: xhci_hcd 0000:0c:00.0: new USB bus registered, assigned bus number 2
Jan 19 18:04:54 archlinux kernel: xhci_hcd 0000:0c:00.0: Host supports USB 3.2 Enhanced SuperSpeed
Jan 19 18:04:58 archlinux kernel: usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.12
Jan 19 18:04:58 archlinux kernel: usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1

That's 4 seconds where it appears everything is on hold waiting for that USB device to come online.

These entries indicate that your shutdowns aren't clean:

Jan 19 18:05:00 Emres-PC systemd-journald[445]: File /var/log/journal/f63493dd01794b3ea2e418713e94331c/system.journal corrupted or uncleanly shut down, renaming and replacing.
Jan 19 18:05:00 Emres-PC kernel: FAT-fs (nvme0n1p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

What service is logging these entries? They look suspiciously like some kind of auto-updater that runs on boot:

Jan 19 18:05:00 Emres-PC systemd[1]: Starting Update is Completed...
Jan 19 18:05:01 Emres-PC systemd[1]: Finished Update is Completed.

It also appears you have more than one network connected: wired + wireless. Is that by design, or omission?

Jan 19 18:05:04 Emres-PC NetworkManager[701]: <info>  [1737306304.5226] device (eno1): carrier: link connected
...
Jan 19 18:05:07 Emres-PC wpa_supplicant[781]: wlp11s0: SME: Trying to authenticate with XXXX (SSID='S-Online' freq=5580 MHz)

SevenStart · 2025-01-21 18:22:56

jl2 wrote:

No the point is you should now be able to see the console output and see where it hangs.
Also remove quiet, loglevel, splash, and plymouth kernel parameters.
~~Can we have a journal output?~~my bad didn't see.
For the UKI, see https://wiki.archlinux.org/title/Unified_kernel_image

Thank you for the suggestion!

That said, I tried removing plymouth and quiet from the boot parameters as you suggested, and unfortunately, I didn’t find anything unusual in the boot logs that would explain the delay at GDM.
The system boots smoothly to GDM in around 10 seconds (excluding the 3-second kernel selection delay), so the issue seems to be isolated to the transition from GDM to GNOME Shell, where the delay still occurs.

SevenStart · 2025-01-21 18:40:35

Thank you for your detailed response and suggestions!

twelveeighty wrote:

Your boot sequence is blocking/waiting for bluetooth - this might actually be your longest wait - try disabling bluetooth and see if that speeds things up:
Jan 19 18:05:20 Emres-PC kernel: Bluetooth: hci0: Device setup in 20454346 usecs

Disabling Bluetooth did indeed have a small effect, but it didn’t resolve the main issue. On Wayland, after entering my password, the screen now turns black (instead of keeping the gray GDM background), a behavior that previously only occurred on Xorg. However, the delay from GDM to GNOME Shell remains unchanged, with the screen staying black until the CPU fans momentarily spin up. Only after this spin-up does the system proceed to display the GNOME Shell.

twelveeighty wrote:

Also look into the following issues:

Jan 19 18:04:54 archlinux kernel: xhci_hcd 0000:0c:00.0: new USB bus registered, assigned bus number 2
Jan 19 18:04:54 archlinux kernel: xhci_hcd 0000:0c:00.0: Host supports USB 3.2 Enhanced SuperSpeed
Jan 19 18:04:58 archlinux kernel: usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.12
Jan 19 18:04:58 archlinux kernel: usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1

That's 4 seconds where it appears everything is on hold waiting for that USB device to come online.

I’m not sure which USB device is causing this delay. I currently have a USB hub, a USB-C cable to charge my wireless Logitech mouse, a USB cable connected to my wired keyboard, and two dongles—one for the mouse and another for my Logitech wireless headset. To troubleshoot, I tried unplugging all USB devices except for the mouse and keyboard (as I cannot boot without the keyboard due to an error from either the BIOS or systemd-boot). Unfortunately, this didn’t make any difference.

twelveeighty wrote:

These entries indicate that your shutdowns aren't clean:

Jan 19 18:05:00 Emres-PC systemd-journald[445]: File /var/log/journal/f63493dd01794b3ea2e418713e94331c/system.journal corrupted or uncleanly shut down, renaming and replacing.
Jan 19 18:05:00 Emres-PC kernel: FAT-fs (nvme0n1p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

This likely stems from how I’ve been shutting down the system—often directly via the terminal using

sudo reboot

or

sudo shutdown -h 0

for convenience, especially when I’m working in the terminal and need to reboot quickly.

twelveeighty wrote:

What service is logging these entries? They look suspiciously like some kind of auto-updater that runs on boot:
Jan 19 18:05:00 Emres-PC systemd[1]: Starting Update is Completed...
Jan 19 18:05:01 Emres-PC systemd[1]: Finished Update is Completed.

I’m unsure which service is responsible. It might be related to vestktop, as I have auto-updates enabled there, but I’m not entirely certain.

twelveeighty wrote:

It also appears you have more than one network connected: wired + wireless. Is that by design, or omission?
Jan 19 18:05:04 Emres-PC NetworkManager[701]: <info>  [1737306304.5226] device (eno1): carrier: link connected
...
Jan 19 18:05:07 Emres-PC wpa_supplicant[781]: wlp11s0: SME: Trying to authenticate with XXXX (SSID='S-Online' freq=5580 MHz)

I’ve disabled WiFi as well, which I had intentionally kept enabled as a fallback in case my wired connection went down to ensure uninterrupted work. Unfortunately, disabling it didn’t make any noticeable difference either.

mcpalls · 2025-01-21 22:04:17

have you tried a kernel downgrade?
6.12.8

twelveeighty · 2025-01-22 00:26:38

SevenStart wrote:

This likely stems from how I’ve been shutting down the system

No, you're misunderstanding how 'shutdown' and 'reboot' work - they perform a 'clean' shutdown and will (should) properly unmount partitions & devices, unless perhaps device timeouts occur. After a reboot or shutdown/start, check your journal entries from the last shutdown using 'journalctl -b -1' and look for anomalies during shutdown. The kernel error message was for a FAT-fs filesystem, so I guess that's your boot partition that wasn't shut down properly?

-- Edit: hit Submit too early ---

There's also a LOT of gnome-shell errors in your logs. I stay away from GNOME as far as possible, so I do not know if that journal log diarrhea is considered "normal", but as a test I would highly recommend installing another light-weight WM alongside GNOME and see if that login experience is a lot snappier. To keep things clean, I'd recommend creating a new 'test' user that you use to log into that WM and leave your regular user untouched.

Last edited by twelveeighty (2025-01-22 00:33:34)

seth · 2025-01-22 08:36:47

test installation of Windows 10 on the same system resulted in boot times of just 10–15 seconds

system boots up to the GDM greeter in about 10–24 seconds. After entering my password, there’s a 30-second delay before the GNOME shell loads

Arch *boots* in 10-24s, when you see GDM, the boot is long finished.
The problem is your session.

In the specific case

Jan 19 18:04:54 archlinux kernel: Linux version 6.12.9-arch1-1 (linux@archlinux) (gcc (GCC) 14.2.1 20240910, GNU ld (GNU Binutils) 2.43.1) #1 SMP PREEMPT_DYNAMIC Fri, 10 Jan 2025 00:39:41 +0000
Jan 19 18:04:59 Emres-PC systemd[1]: Queued start job for default target Graphical Interface.
Jan 19 18:05:02 Emres-PC systemd-logind[705]: New session 2 of user gdm.
Jan 19 18:05:02 Emres-PC systemd[1]: Started Session 1 of User gdm.
Jan 19 18:05:06 Emres-PC systemd-logind[705]: New session 4 of user emre.
Jan 19 18:05:26 Emres-PC systemd[1]: Reached target Graphical Interface.

The boot takes <5s, GDM takes another 3s, you login after 11s total, then gnome takes 20s

BT and wifi stick out in the journal, but apparently that's not it.
You've two amdgpu VGA devices, what happens if you disable the APU graphics?

Does gnome on X11 start faster?
Also please post an updated "clean" journal for the BT/Wifi-less situation.

Awebb · 2025-01-22 11:40:46

Sorry for not replying sooner. I actually meant trying without UKI and some bootloader to verify it's not the UKI setup. However, I misread, the 27 seconds were not for initrd but for userspace. You can disregard that part of my comment.

Arch Linux

#1 2025-01-19 18:57:02