Slow Boot Process, sluggish system, rpm-ostree gets stuck

Ask Fedora
1

Hello all,

after my latest update on Fedora Silverblue the boot process has become very slow together with weird graphics. Normally I am shown a “graphical interface" asking for my LUKS passphrase, now after a while I receive only a text line.

As mentioned, it takes very long for the GNOME login screen to appear and then again the system freezes shortly before starting the graphical desktop.

I checked with systemd and interestingly a fuse service came up as one possible culprit

systemd-analyze blame
44.605s sys-module-fuse.device
43.590s sys-devices-LNXSYSTM:00-LNXSYBUS:00-MSFT0101:00-tpm-tpm0.device
43.590s dev-tpm0.device
43.395s dev-tpmrm0.device
43.395s sys-devices-LNXSYSTM:00-LNXSYBUS:00-MSFT0101:00-tpmrm-tpmrm0.device
43.381s dev-ttyS2.device
43.381s sys-devices-platform-serial8250-serial8250:0-serial8250:0.2-tty-ttyS2.device
43.363s dev-ttyS1.device
43.363s sys-devices-platform-serial8250-serial8250:0-serial8250:0.1-tty-ttyS1.device
43.362s dev-ttyS3.device
43.362s sys-devices-platform-serial8250-serial8250:0-serial8250:0.3-tty-ttyS3.device
43.347s sys-devices-platform-serial8250-serial8250:0-serial8250:0.0-tty-ttyS0.device
43.347s dev-ttyS0.device
43.272s sys-module-configfs.device
42.879s dev-disk-by\x2duuid-4FFE\x2d09DA.device
42.879s dev-disk-by\x2did-nvme\x2deui.0025384c3140b46c\x2dpart1.device
42.879s dev-disk-by\x2ddiskseq-1\x2dpart1.device
42.879s dev-disk-by\x2dpath-pci\x2d0000:02:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartlabel-EFI\x5cx20System\x5cx20Partition.device
42.879s dev-disk-by\x2dpath-pci\x2d0000:02:00.0\x2dnvme\x2d1\x2dpart-by\x2duuid-4FFE\x2d09DA.device
42.879s dev-disk-by\x2dpath-pci\x2d0000:02:00.0\x2dnvme\x2d1\x2dpart1.device
42.879s dev-disk-by\x2dpath-pci\x2d0000:02:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartuuid-5d3f17ab\x2d5737\x2d4521\x2db824\x2d07b391305a98.device
42.879s sys-devices-pci0000:00-0000:00:06.2-0000:02:00.0-nvme-nvme0-nvme0n1-nvme0n1p1.device
42.879s dev-disk-by\x2dpartlabel-EFI\x5cx20System\x5cx20Partition.device
42.879s dev-disk-by\x2dpath-pci\x2d0000:02:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartnum-1.device
42.879s dev-nvme0n1p1.device
42.879s dev-disk-by\x2did-nvme\x2dSamsung_SSD_990_PRO_2TB_S7DNNJ0WC16368P_1\x2dpart1.device
42.879s dev-disk-by\x2dpartuuid-5d3f17ab\x2d5737\x2d4521\x2db824\x2d07b391305a98.device
42.879s dev-disk-by\x2did-nvme\x2dSamsung_SSD_990_PRO_2TB_S7DNNJ0WC16368P\x2dpart1.device
42.840s dev-disk-by\x2duuid-4a3d4c2d\x2d6b91\x2d4543\x2dbe49\x2def9c869f3dcd.device
42.840s sys-devices-pci0000:00-0000:00:06.2-0000:02:00.0-nvme-nvme0-nvme0n1-nvme0n1p3.device
42.840s dev-disk-by\x2did-nvme\x2deui.0025384c3140b46c\x2dpart3.device
42.840s dev-disk-by\x2did-nvme\x2dSamsung_SSD_990_PRO_2TB_S7DNNJ0WC16368P\x2dpart3.device
42.840s dev-disk-by\x2ddiskseq-1\x2dpart3.device
42.840s dev-disk-by\x2dpath-pci\x2d0000:02:00.0\x2dnvme\x2d1\x2dpart-by\x2duuid-4a3d4c2d\x2d6b91\x2d4543\x2dbe49\x2def9c869f3dcd.device
42.840s dev-nvme0n1p3.device
42.840s dev-disk-by\x2dpartuuid-8fe4bf62\x2dd53b\x2d48fe\x2dade9\x2dca20d046e28e.device
42.840s dev-disk-by\x2dpath-pci\x2d0000:02:00.0\x2dnvme\x2d1\x2dpart3.device
42.840s dev-disk-by\x2did-nvme\x2dSamsung_SSD_990_PRO_2TB_S7DNNJ0WC16368P_1\x2dpart3.device
42.840s dev-disk-by\x2dpath-pci\x2d0000:02:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartuuid-8fe4bf62\x2dd53b\x2d48fe\x2dade9\x2dca20d046e28e.device
42.840s dev-disk-by\x2dpath-pci\x2d0000:02:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartnum-3.device
42.746s dev-nvme0n1.device
42.746s dev-disk-by\x2ddiskseq-1.device
42.746s sys-devices-pci0000:00-0000:00:06.2-0000:02:00.0-nvme-nvme0-nvme0n1.device
42.746s dev-disk-by\x2did-nvme\x2dSamsung_SSD_990_PRO_2TB_S7DNNJ0WC16368P_1.device
42.746s dev-disk-by\x2dpath-pci\x2d0000:02:00.0\x2dnvme\x2d1.device
42.746s dev-disk-by\x2did-nvme\x2dSamsung_SSD_990_PRO_2TB_S7DNNJ0WC16368P.device
42.746s dev-disk-by\x2did-nvme\x2deui.0025384c3140b46c.device
42.720s dev-disk-by\x2dpath-pci\x2d0000:02:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartnum-2.device
42.720s dev-disk-by\x2did-nvme\x2dSamsung_SSD_990_PRO_2TB_S7DNNJ0WC16368P_1\x2dpart2.device
42.720s dev-nvme0n1p2.device
42.720s dev-disk-by\x2dpartuuid-94229b96\x2dbe32\x2d41cd\x2dbb81\x2d3ef58fdd47cc.device
42.720s dev-disk-by\x2dpath-pci\x2d0000:02:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartuuid-94229b96\x2dbe32\x2d41cd\x2dbb81\x2d3ef58fdd47cc.device
42.720s sys-devices-pci0000:00-0000:00:06.2-0000:02:00.0-nvme-nvme0-nvme0n1-nvme0n1p2.device
42.720s dev-disk-by\x2dpath-pci\x2d0000:02:00.0\x2dnvme\x2d1\x2dpart-by\x2duuid-5a40ecc2\x2d3203\x2d44e2\x2d87c3\x2de53c8e881741.device
42.720s dev-disk-by\x2duuid-5a40ecc2\x2d3203\x2d44e2\x2d87c3\x2de53c8e881741.device
42.720s dev-disk-by\x2did-nvme\x2dSamsung_SSD_990_PRO_2TB_S7DNNJ0WC16368P\x2dpart2.device
42.720s dev-disk-by\x2ddiskseq-1\x2dpart2.device
42.720s dev-disk-by\x2dpath-pci\x2d0000:02:00.0\x2dnvme\x2d1\x2dpart2.device
42.720s dev-disk-by\x2did-nvme\x2deui.0025384c3140b46c\x2dpart2.device
36.337s dracut-initqueue.service
35.257s systemd-cryptsetup@luks\x2d4a3d4c2d\x2d6b91\x2d4543\x2dbe49\x2def9c869f3dcd.service
34.755s sys-devices-pci0000:00-0000:00:02.0-drm-card1-card1\x2deDP\x2d1-intel_backlight.device
11.549s plymouth-quit-wait.service

I am more than thankful for ideas on how to analyze this further. While booting, no external drives are attached.

Going back to a previous deployment, even the pristine one after the initial install, results in the same behavior.

I checked if something is wrong with the file system



sudo btrfs device stats /dev/dm-0

[/dev/mapper/luks-4a3d4c2d-6b91-4543-be49-ef9c869f3dcd].write_io_errs    0
[/dev/mapper/luks-4a3d4c2d-6b91-4543-be49-ef9c869f3dcd].read_io_errs     0
[/dev/mapper/luks-4a3d4c2d-6b91-4543-be49-ef9c869f3dcd].flush_io_errs    0
[/dev/mapper/luks-4a3d4c2d-6b91-4543-be49-ef9c869f3dcd].corruption_errs  0
[/dev/mapper/luks-4a3d4c2d-6b91-4543-be49-ef9c869f3dcd].generation_errs  0

As for rpm-ostree (AI gave me the hint to check, whether my system is trying to fetch some data from repositories during the boot process) it looks like this.



rpm-ostree status -v
State: idle
AutomaticUpdates: disabled
Deployments:
fedora:fedora/43/x86_64/silverblue (index: 0)
Version: 43.20260211.0 (2026-02-11T01:21:41Z)
BaseCommit: ec73495c511530de7716612290ac0bc0f476ceba73bbce6b2cabadd3d52a5583
├─ repo-0 (2025-10-23T03:37:20Z)
├─ repo-1 (2026-02-11T01:02:41Z)
└─ repo-2 (2026-02-11T01:04:13Z)
Commit: db28e6f90f59aa5f8402f46b4768fb5941cf0d04c24eb4262a44b1352034c41e
├─ copr:copr.fedorainfracloud.org:phracek:PyCharm (2026-01-03T12:40:14Z)
├─ fedora (2025-10-23T03:37:20Z)
├─ fedora-cisco-openh264 (2025-03-05T10:45:56Z)
├─ updates (2026-02-11T05:51:43Z)
└─ updates-archive (2026-02-11T06:14:51Z)
Staged: yes
StateRoot: fedora
GPGSignature: 1 signature
Signature made Mi 11 Feb 2026 02:23:20 CET using RSA key ID 829B606631645531
Good signature from “Fedora fedora-43-primary@fedoraproject.org”
Upgraded: gnome-settings-daemon 49.1-1.fc43 → 49.1-2.fc43
hwdata 0.403-1.fc43 → 0.404-1.fc43
systemd 258.3-3.fc43 → 258.4-1.fc43
systemd-container 258.3-3.fc43 → 258.4-1.fc43
systemd-libs 258.3-3.fc43 → 258.4-1.fc43
systemd-networkd 258.3-3.fc43 → 258.4-1.fc43
systemd-oomd-defaults 258.3-3.fc43 → 258.4-1.fc43
systemd-pam 258.3-3.fc43 → 258.4-1.fc43
systemd-resolved 258.3-3.fc43 → 258.4-1.fc43
systemd-shared 258.3-3.fc43 → 258.4-1.fc43
systemd-sysusers 258.3-3.fc43 → 258.4-1.fc43
systemd-udev 258.3-3.fc43 → 258.4-1.fc43
LayeredPackages: distrobox gstreamer1-plugin-openh264 texlive-scheme-full vim

Maybe this information gives some hints for more expert users, what might have gone wrong.

As for the hardware I am on a Tuxedo Infinity Book Pro 14. The system ran fine after the first install and the next 4 upgrades. In the meantime, I set up a SSH key and added it to my agent, this shouldn’t be an issue, should it? I installed a few programs, (htop, krusader) via distrobox and exported it to my host system, sound strange to me if this would slow down the boot process or create problems for rpm-ostree.

Fedora Kinoite: systemd degraded upon installation
2

As it might be relevant, here is my /etc/fstab

# Updated by bootc-fstab-edit.service
UUID=8b3be73f-77bd-4dc0-9efd-d1578d945c55 / btrfs subvol=root,compress=zstd:1,x-systemd.device-timeout=0,ro 0 0
UUID=5a40ecc2-3203-44e2-87c3-e53c8e881741 /boot ext4 defaults 1 2
UUID=4FFE-09DA /boot/efi vfat umask=0077,shortname=winnt 0 2
UUID=8b3be73f-77bd-4dc0-9efd-d1578d945c55 /home btrfs subvol=home,compress=zstd:1,x-systemd.device-timeout=0 0 0
UUID=8b3be73f-77bd-4dc0-9efd-d1578d945c55 /var btrfs subvol=var,compress=zstd:1,x-systemd.device-timeout=0 0 0
3

Have you had a look at the journal? After journalctl -b shows the logs since boot. In cases like these, I would expect one of the following issues:

  • an application crashing, maybe even repeatedly. This should be listed in the logs, or visible with coredumpctl list
  • the disk being full. df -H should show you how full your disks are. Also, some hints to that would probably be shown in the logs
  • some hardware problem. journalctl -b -k or dmesg give a more concise log from the kernel, which may make it easier to find the relevant problem.
  • some memory bug causing the system to run out of memory. You can test that with free -h, which should show you usage of RAM and swap

Also, what does systemctl status show, especially in the first few lines? Does it say State: degraded or State: running?

EDIT: All the ideas above are independent from whether it is an atomic desktop (using rpm-ostree) or not.

1 Like
5

Could you post the full output of the rpm-ostree status --verbose command?

1 Like
6

Hi Christian,

first of all many thanks for your time and support.

I noticed an issue with Gnome Session Manager for one thing, the executable doesn’t exist.



coredumpctl list
TIME                           PID   UID  GID SIG     COREFILE     EXE                                  SIZE
Thu 2026-02-05 16:31:02 CET   1957 60578  983 SIGABRT inaccessible /usr/libexec/gnome-session-service      -
Mon 2026-02-09 17:32:21 CET   5587  1000 1000 SIGABRT present      /usr/libexec/gsd-media-keys        452.7K
Mon 2026-02-09 17:32:22 CET  31057  1000 1000 SIGABRT present      /usr/libexec/gsd-media-keys        447.5K
Wed 2026-02-11 17:36:52 CET   4875  1000 1000 SIGABRT present      /usr/libexec/gsd-media-keys        526.1K
Wed 2026-02-11 17:37:59 CET  83571  1000 1000 SIGABRT present      /usr/libexec/gsd-media-keys        445.4K
Wed 2026-02-11 17:39:19 CET  85473  1000 1000 SIGABRT present      /usr/libexec/gsd-media-keys        448.2K
Wed 2026-02-11 17:40:03 CET  86598  1000 1000 SIGABRT present      /usr/libexec/gsd-media-keys        445.2K
Wed 2026-02-11 17:41:29 CET  87131  1000 1000 SIGABRT present      /usr/libexec/gsd-media-keys        444.9K
Wed 2026-02-11 17:42:54 CET  88148  1000 1000 SIGABRT present      /usr/libexec/gsd-media-keys        445.1K
Wed 2026-02-11 17:48:30 CET  89199  1000 1000 SIGABRT present      /usr/libexec/gsd-media-keys        445.7K
Wed 2026-02-11 17:54:09 CET  98278  1000 1000 SIGABRT present      /usr/libexec/gsd-media-keys        447.8K
Wed 2026-02-11 18:14:27 CET 107458  1000 1000 SIGABRT present      /usr/libexec/gsd-media-keys        518.3K
Wed 2026-02-11 18:15:07 CET 158756  1000 1000 SIGABRT present      /usr/libexec/gsd-media-keys        444.4K
Wed 2026-02-11 18:29:14 CET   3962  1000 1000 SIGABRT present      /usr/libexec/gsd-media-keys        445.6K
Wed 2026-02-11 18:41:01 CET  17100  1000 1000 SIGABRT present      /usr/libexec/gsd-media-keys        446.9K

The boot partition is filling somewhat and composefs partition is full - . I unpinned unused deployments and did ostree admin cleanup.

Sorting used disk space by percentage of the partition in question:

df -Th | sort -nk6

Dateisystem    Typ      Größe Benutzt Verf. Verw% Eingehängt auf
devtmpfs       devtmpfs   32G       0   32G    0% /dev
tmpfs          tmpfs     1,0M       0  1,0M    0% /run/credentials/systemd-cryptsetup@luks\x2d4a3d4c2d\x2d6b91\x2d4543\x2dbe49\x2def9c869f3dcd.service
tmpfs          tmpfs     1,0M       0  1,0M    0% /run/credentials/systemd-journald.service
tmpfs          tmpfs     1,0M       0  1,0M    0% /run/credentials/systemd-resolved.service
/dev/sda1      exfat      58G     43M   58G    1% /run/media/pascal/7ABB-E2D4
tmpfs          tmpfs      13G    2,2M   13G    1% /run
tmpfs          tmpfs      32G     24M   32G    1% /tmp
tmpfs          tmpfs      32G     92K   32G    1% /dev/shm
tmpfs          tmpfs     6,3G    256K  6,3G    1% /run/user/1000
/dev/nvme0n1p1 vfat      599M     13M  587M    3% /boot/efi
/dev/dm-0      btrfs     1,9T     90G  1,8T    5% /etc
/dev/dm-0      btrfs     1,9T     90G  1,8T    5% /var
/dev/dm-0      btrfs     1,9T     90G  1,8T    5% /var/home
efivarfs       efivarfs  192K    120K   68K   64% /sys/firmware/efi/efivars
/dev/nvme0n1p2 ext4      2,0G    1,2G  614M   67% /boot
composefs      overlay    64M     64M     0  100% /

Memory should be more than enough free -h

total used free shared buff/cache availableMem: 62Gi 6,3Gi 49Gi 1,8Gi 8,6Gi 56GiSwap: 8,0Gi 0B 8,0Gi

Regarding hardware issue, I filtered the lines where journalctl highlighted problems - posting the entire output seemed overkill to me, correct me, if my assumption wrong

journalctl -b -k 

Feb 07 01:00:00 fedora kernel: Kernel command line: BOOT_IMAGE=(hd0,gpt2)/ostree/fedora-132aece156fe4a08ec0b4fac17171ce75beda11a19e7a0091555875dbf128353/vmlinuz-6.18.8-20>
Feb 07 01:00:00 fedora kernel: Unknown kernel command line parameters "rhgb ostree=/ostree/boot.0/fedora/132aece156fe4a08ec0b4fac17171ce75beda11a19e7a0091555875dbf128353/>

…

Feb 07 01:00:00 fedora kernel: resource: resource sanity check: requesting [mem 0x00000000fe410497-0x00000000fe411496], which spans more than INOU0000:00 [mem 0xfe410000->
Feb 07 01:00:00 fedora kernel: caller acpi_os_map_iomem+0x1cb/0x200 mapping multiple BARs
Feb 07 01:00:00 fedora kernel: ACPI: battery: Slot [BAT0] (battery present)
Feb 07 01:00:00 fedora kernel: hpet_acpi_add: no address or irqs in _CRS

…

Feb 07 01:00:00 fedora kernel: i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
Feb 07 01:00:00 fedora kernel: i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
Feb 07 01:00:00 fedora kernel: serio: i8042 KBD port at 0x60,0x64 irq 1
Feb 07 01:00:00 fedora kernel: mousedev: PS/2 mouse device common for all mice
Feb 07 01:00:00 fedora kernel: rtc_cmos rtc_cmos: RTC can wake from S4
Feb 07 01:00:00 fedora kernel: rtc_cmos rtc_cmos: registered as rtc0
Feb 07 01:00:00 fedora kernel: rtc_cmos rtc_cmos: setting system clock to 2021-01-01T00:00:07 UTC (1609459207)
Feb 07 01:00:00 fedora kernel: rtc_cmos rtc_cmos: alarms up to one month, y3k, 114 bytes nvram
Feb 07 01:00:00 fedora kernel: input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
Feb 07 01:00:00 fedora kernel: device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. Duplicate IMA measurements will not be recorded in the IMA log.

…

Feb 07 01:00:37 SilverFed kernel: zram: Added device: zram0
Feb 07 01:00:37 SilverFed kernel: ACPI BIOS Error (bug): Could not resolve symbol [^^^^NPCF.ACBT], AE_NOT_FOUND (20250807/psargs-332)
Feb 07 01:00:37 SilverFed kernel: ACPI Error: Aborting method _SB.PC00.LPCB.EC0._Q83 due to previous error (AE_NOT_FOUND) (20250807/psparse-529)

…

Feb 07 01:00:37 SilverFed systemd[1]: modprobe@loop.service: Deactivated successfully.
Feb 07 01:00:37 SilverFed systemd[1]: Finished modprobe@loop.service - Load Kernel Module loop.
Feb 07 01:00:37 SilverFed systemd[1]: systemd-repart.service - Repartition Root Disk skipped, no trigger condition checks were met.
Feb 07 01:00:37 SilverFed systemd[1]: systemd-remount-fs.service: Main process exited, code=exited, status=1/FAILURE
Feb 07 01:00:37 SilverFed systemd[1]: systemd-remount-fs.service: Failed with result ‘exit-code’.
Feb 07 01:00:37 SilverFed systemd[1]: Failed to start systemd-remount-fs.service - Remount Root and Kernel File Systems.

…

Feb 12 13:49:19 SilverFed kernel: ACPI: EC: interrupt blocked
Feb 12 13:49:19 SilverFed kernel: ACPI: EC: interrupt unblocked
Feb 12 13:49:19 SilverFed kernel: spd5118 13-0050: Failed to write b = 0: -6
Feb 12 13:49:19 SilverFed kernel: spd5118 13-0050: PM: dpm_run_callback(): spd5118_resume [spd5118] returns -6
Feb 12 13:49:19 SilverFed kernel: spd5118 13-0050: PM: failed to resume async: error -6
Feb 12 13:49:19 SilverFed kernel: spd5118 13-0052: Failed to write b = 0: -6
Feb 12 13:49:19 SilverFed kernel: spd5118 13-0052: PM: dpm_run_callback(): spd5118_resume [spd5118] returns -6
Feb 12 13:49:19 SilverFed kernel: spd5118 13-0052: PM: failed to resume async: error -6

Again, many thanks for your efforts and I will remember your hints on how to retrieve more useful information. Already learned a lot more about Linux :+1:

7

I forgot to post the output of systemd status - indeed it is degraded

● SilverFed
    State: degraded
    Units: 477 loaded (incl. loaded aliases)
     Jobs: 0 queued
   Failed: 1 units
    Since: Thu 2026-02-12 18:12:19 CET; 1h 2min ago
  systemd: 258.4-1.fc43
   CGroup: /
           ├─init.scope
           │ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize=57 rhgb
           ├─system.slice
           │ ├─ModemManager.service
           │ │ └─1451 /usr/bin/ModemManager
           │ ├─NetworkManager.service
           │ │ └─1534 /usr/bin/NetworkManager --no-daemon
           │ ├─accounts-daemon.service
           │ │ └─1372 /usr/libexec/accounts-daemon
           │ ├─auditd.service
           │ │ └─1287 /usr/bin/auditd
           │ ├─avahi-daemon.service
           │ │ ├─1330 "avahi-daemon: running [SilverFed.local]"
           │ │ └─1394 "avahi-daemon: chroot helper"
           │ ├─bluetooth.service
           │ │ └─1331 /usr/libexec/bluetooth/bluetoothd
           │ ├─bolt.service
           │ │ └─1453 /usr/libexec/boltd
           │ ├─chronyd.service
           │ │ └─1333 /usr/sbin/chronyd -n -F 2
           │ ├─colord.service
           │ │ └─1849 /usr/libexec/colord
           │ ├─dbus-broker.service
           │ │ ├─1327 /usr/bin/dbus-broker-launch --scope system --audit
           │ │ └─1328 dbus-broker --log 10 --controller 9 --machine-id 11de3eac31b6420d8580e2768ef4c0b1 --max-bytes 536870912 --max-fds 4096 --max-matches 131072 --audit
           │ ├─firewalld.service
           │ │ └─1461 /usr/bin/python3 -sP /usr/bin/firewalld --nofork --nopid
           │ ├─fwupd.service
           │ │ └─5608 /usr/libexec/fwupd/fwupd
           │ ├─gdm.service
           │ │ └─1586 /usr/bin/gdm
           │ ├─geoclue.service
           │ │ └─2076 /usr/libexec/geoclue
           │ ├─gssproxy.service
           │ │ └─1570 /usr/bin/gssproxy -i
           │ ├─low-memory-monitor.service
           │ │ └─1338 /usr/libexec/low-memory-monitor
           │ ├─mcelog.service
           │ │ └─1340 /usr/sbin/mcelog --daemon --foreground
           │ ├─pcscd.service
           │ │ └─1956 /usr/bin/pcscd --foreground --auto-exit
           │ ├─polkit.service
           │ │ └─1342 /usr/lib/polkit-1/polkitd --no-debug --log-level=notice
           │ ├─rtkit-daemon.service
           │ │ └─1344 /usr/libexec/rtkit-daemon
           │ ├─sssd-kcm.service
           │ │ └─8907 /usr/libexec/sssd/sssd_kcm --logger=files
           │ ├─switcheroo-control.service
           │ │ └─1345 /usr/libexec/switcheroo-control
           │ ├─system-cups.slice
           │ │ └─cups.service
           │ │   └─1569 /usr/bin/cupsd -l
           │ ├─systemd-homed.service
           │ │ └─1346 /usr/lib/systemd/systemd-homed
           │ ├─systemd-journald.service
           │ │ └─1014 /usr/lib/systemd/systemd-journald
           │ ├─systemd-logind.service
           │ │ └─1382 /usr/lib/systemd/systemd-logind
           │ ├─systemd-nsresourced.service
           │ │ ├─ 1048 /usr/lib/systemd/systemd-nsresourced
           │ │ ├─14216 "systemd-nsresourcework: waiting..."
           │ │ ├─14217 "systemd-nsresourcework: waiting..."
           │ │ ├─14218 "systemd-nsresourcework: waiting..."
           │ │ ├─14219 "systemd-nsresourcework: waiting..."
           │ │ └─14220 "systemd-nsresourcework: waiting..."
           │ ├─systemd-oomd.service
           │ │ └─1286 /usr/lib/systemd/systemd-oomd
           │ ├─systemd-resolved.service
           │ │ └─1288 /usr/lib/systemd/systemd-resolved
           │ ├─systemd-udevd.service
           │ │ └─udev
           │ │   └─1091 /usr/lib/systemd/systemd-udevd
           │ ├─systemd-userdbd.service
           │ │ ├─ 1046 /usr/lib/systemd/systemd-userdbd
           │ │ ├─11196 "systemd-userwork: waiting..."
           │ │ ├─11197 "systemd-userwork: waiting..."
           │ │ └─12178 "systemd-userwork: waiting..."
           │ ├─thermald.service
           │ │ └─1347 /usr/bin/thermald --systemd --dbus-enable --adaptive
           │ ├─tuned-ppd.service
           │ │ └─1640 /usr/bin/python3 -Es /usr/sbin/tuned-ppd -l
           │ ├─tuned.service
           │ │ └─1572 /usr/bin/python3 -Es /usr/sbin/tuned -l -P
           │ ├─udisks2.service
           │ │ └─1348 /usr/libexec/udisks2/udisksd
           │ ├─upower.service
           │ │ └─1350 /usr/libexec/upowerd
           │ ├─uresourced.service
           │ │ └─1599 /usr/libexec/uresourced
           │ └─wpa_supplicant.service
           │   └─1555 /usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -u -s
           

           ...
8

As already surfaced in journalctl the remount-fs.service is running into trouble:

systemctl list-units --failed

  UNIT                       LOAD   ACTIVE SUB    DESCRIPTION                         
● systemd-remount-fs.service loaded failed failed Remount Root and Kernel File Systems

Legend: LOAD   → Reflects whether the unit definition was properly loaded.
        ACTIVE → The high-level unit activation state, i.e. generalization of SUB.
        SUB    → The low-level unit activation state, values depend on unit type.

Searching further what systemd tells me: systemctl status systemd-remount-fs.service

systemctl status systemd-remount-fs.service
× systemd-remount-fs.service - Remount Root and Kernel File Systems
     Loaded: loaded (/usr/lib/systemd/system/systemd-remount-fs.service; enabled-runtime; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: failed (Result: exit-code) since Thu 2026-02-12 18:12:28 CET; 1h 11min ago
 Invocation: 9098763dc0f9464c983f8c74a86c1e96
       Docs: man:systemd-remount-fs.service(8)
             https://systemd.io/API_FILE_SYSTEMS
    Process: 1202 ExecStart=/usr/lib/systemd/systemd-remount-fs (code=exited, status=1/FAILURE)
   Main PID: 1202 (code=exited, status=1/FAILURE)
   Mem peak: 1.6M
        CPU: 51ms

Feb 12 18:12:27 SilverFed systemd[1]: Starting systemd-remount-fs.service - Remount Root and Kernel File Systems...
Feb 12 18:12:28 SilverFed systemd-remount-fs[1210]: mount: /: fsconfig() failed: overlay: No changes allowed in reconfigure.My
Feb 12 18:12:28 SilverFed systemd-remount-fs[1210]:        dmesg(1) may have more information after failed mount system call.
Feb 12 18:12:28 SilverFed systemd-remount-fs[1202]: /usr/bin/mount for / exited with exit status 32.
Feb 12 18:12:28 SilverFed systemd[1]: systemd-remount-fs.service: Main process exited, code=exited, status=1/FAILURE
Feb 12 18:12:28 SilverFed systemd[1]: systemd-remount-fs.service: Failed with result 'exit-code'.
Feb 12 18:12:28 SilverFed systemd[1]: Failed to start systemd-remount-fs.service - Remount Root and Kernel File Systems.

My /etc/fstab looks like this, created during the initial install:

# /etc/fstab
# Created by anaconda on Thu Feb  5 15:23:57 2026
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
# Updated by bootc-fstab-edit.service
UUID=8b3be73f-77bd-4dc0-9efd-d1578d945c55 / btrfs subvol=root,compress=zstd:1,x-systemd.device-timeout=0,ro 0 0
UUID=5a40ecc2-3203-44e2-87c3-e53c8e881741 /boot ext4 defaults 1 2
UUID=4FFE-09DA /boot/efi vfat umask=0077,shortname=winnt 0 2
UUID=8b3be73f-77bd-4dc0-9efd-d1578d945c55 /home btrfs subvol=home,compress=zstd:1,x-systemd.device-timeout=0 0 0
UUID=8b3be73f-77bd-4dc0-9efd-d1578d945c55 /var btrfs subvol=var,compress=zstd:1,x-systemd.device-timeout=0 0 0
Fedora Kinoite: systemd degraded upon installation
9

Hello @hricky

Really appreciate your support.

Here is what rpm-ostree tells me: rpm-ostree status --verbose

rpm-ostree status --verbose
State: idle
AutomaticUpdates: disabled
Deployments:
● fedora:fedora/43/x86_64/silverblue (index: 0)
                  Version: 43.20260212.0 (2026-02-12T00:34:15Z)
               BaseCommit: 2818bff51b59f922898ddab882a537ccf526b4930bb71a9f9509a1d7f44d964a
                           ├─ repo-0 (2025-10-23T03:37:20Z)
                           ├─ repo-1 (2026-02-12T00:15:54Z)
                           └─ repo-2 (2026-02-12T00:17:49Z)
                   Commit: 477691bbfdc4b267e8e3546561bf1b5dd9da09b82aa8ec078020420d9d539bbe
                           ├─ fedora (2025-10-23T03:37:20Z)
                           ├─ fedora-cisco-openh264 (2025-03-05T10:45:56Z)
                           ├─ updates (2026-02-12T00:48:17Z)
                           └─ updates-archive (2026-02-12T01:13:50Z)
                   Staged: no
                StateRoot: fedora
             GPGSignature: 1 signature
                           Signature made Do 12 Feb 2026 01:41:14 CET using RSA key ID 829B606631645531
                           Good signature from "Fedora <fedora-43-primary@fedoraproject.org>"
          LayeredPackages: distrobox gstreamer1-plugin-openh264 texlive-scheme-full vim
                   Pinned: yes

  fedora:fedora/43/x86_64/silverblue (index: 1)
                  Version: 43.20260211.0 (2026-02-11T01:21:41Z)
               BaseCommit: ec73495c511530de7716612290ac0bc0f476ceba73bbce6b2cabadd3d52a5583
                           ├─ repo-0 (2025-10-23T03:37:20Z)
                           ├─ repo-1 (2026-02-11T01:02:41Z)
                           └─ repo-2 (2026-02-11T01:04:13Z)
                   Commit: db28e6f90f59aa5f8402f46b4768fb5941cf0d04c24eb4262a44b1352034c41e
                           ├─ copr:copr.fedorainfracloud.org:phracek:PyCharm (2026-01-03T12:40:14Z)
                           ├─ fedora (2025-10-23T03:37:20Z)
                           ├─ fedora-cisco-openh264 (2025-03-05T10:45:56Z)
                           ├─ updates (2026-02-11T05:51:43Z)
                           └─ updates-archive (2026-02-11T06:14:51Z)
                StateRoot: fedora
             GPGSignature: 1 signature
                           Signature made Mi 11 Feb 2026 02:23:20 CET using RSA key ID 829B606631645531
                           Good signature from "Fedora <fedora-43-primary@fedoraproject.org>"
          LayeredPackages: distrobox gstreamer1-plugin-openh264 texlive-scheme-full vim
                   Pinned: yes

  fedora:fedora/43/x86_64/silverblue (index: 2)
                  Version: 43.20260210.0 (2026-02-10T01:04:25Z)
               BaseCommit: c36ab0f26fe4de896e9b883ef4e88f5a1ad852c527f655ce20783c760371c5c2
                           ├─ repo-0 (2025-10-23T03:37:20Z)
                           ├─ repo-1 (2026-02-10T00:20:38Z)
                           └─ repo-2 (2026-02-10T00:22:46Z)
                   Commit: a52863c66fab4ae9d5be356ad00da41d9034b35feaecbae1c7c2b49cb5472350
                           ├─ copr:copr.fedorainfracloud.org:phracek:PyCharm (2026-01-03T12:40:14Z)
                           ├─ fedora (2025-10-23T03:37:20Z)
                           ├─ fedora-cisco-openh264 (2025-03-05T10:45:56Z)
                           ├─ rpmfusion-nonfree-nvidia-driver (2025-12-19T13:26:34Z)
                           ├─ rpmfusion-nonfree-steam (2025-12-15T14:49:42Z)
                           ├─ updates (2026-02-10T01:21:24Z)
                           └─ updates-archive (2026-02-10T02:27:30Z)
                StateRoot: fedora
             GPGSignature: 1 signature
                           Signature made Di 10 Feb 2026 02:05:56 CET using RSA key ID 829B606631645531
                           Good signature from "Fedora <fedora-43-primary@fedoraproject.org>"
          LayeredPackages: distrobox gstreamer1-plugin-openh264 texlive-scheme-full vim
                   Pinned: yes

  fedora:fedora/43/x86_64/silverblue (index: 3)
                  Version: 43.1.6 (2025-10-23T03:11:18Z)
                   Commit: 4d40d281be93a88f3d559b5756df602f454f932f3c809a6a4250b91049ce40e8
                           ├─ repo-0 (2025-10-23T02:55:59Z)
                           └─ repo-1 (2025-10-23T03:00:03Z)
                StateRoot: fedora
             GPGSignature: 1 signature
                           Signature made Do 23 Okt 2025 05:13:10 CEST using RSA key ID 829B606631645531
                           Good signature from "Fedora <fedora-43-primary@fedoraproject.org>"
                   Pinned: yes

I noticed that I neither need nor use the repositories for proprietarie things like Chrome or Nvidia, so I deactivated them. I believe I was asked by the installer, if I wanted to have them available.

10

I’m not a silverblue or atomic user, but that overlay error… I would take that to mean that after boot the remounter service is trying to remount / with different options and failing to do so as it’s a reconfiguration of a read only root filesystem. At least that’s what it reads like from the errors.

Should your /etc/fstab actually have an entry for / in it at all?

2 Likes
11

Good point. I had somehow overlooked the /etc/fstab info until now.

Try the following workaround to see if it gets any better.

2 Likes
12

Thanks for the link to the tutorial

This fixed the issue with the failed remount-fs.service

systemctl status systemd-remount-fs.service

● systemd-remount-fs.service - Remount Root and Kernel File Systems
     Loaded: loaded (/usr/lib/systemd/system/systemd-remount-fs.service; enabled-runtime; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (exited) since Fri 2026-02-13 13:55:26 CET; 1min 13s ago
 Invocation: 0a9f2396b09146fa8b0bfc8c1fdb47c8
       Docs: man:systemd-remount-fs.service(8)
             https://systemd.io/API_FILE_SYSTEMS
    Process: 1019 ExecStart=/usr/lib/systemd/systemd-remount-fs (code=exited, status=0/SUCCESS)
   Main PID: 1019 (code=exited, status=0/SUCCESS)
   Mem peak: 1.3M
        CPU: 17ms

Booting still seems rather slow, but maybe I am too demanding here. BTW, the entire system is encrypted via LUKS

systemd-analyze blame
19.581s sys-module-fuse.device

I tried to investigate further what takes sys–module-fuse.device so long

systemctl list-dependencies sys-module-fuse.device

systemctl list-dependencies sys-module-fuse.device
sys-module-fuse.device
● └─sys-fs-fuse-connections.mount

But depending service sys-fs-fuse-connections.mount is rather quick

systemd-analyze critical-chain sys-fs-fuse-connections.mount

systemd-analyze critical-chain sys-fs-fuse-connections.mount


sys-fs-fuse-connections.mount +24ms
└─systemd-journald.socket
  └─system.slice
    └─-.slice
13

systemd-analyze plot can be useful in these scenarios.

1 Like
14

Your assumption CAN be true, but if the issue is not found otherwise, you might want to give a full journal for review. Sometimes error messages are only symptoms and the origin occurs much earlier, and not every cause of issues is inevitably mentioned as error itself. Also, journals add context. While I don’t know if I can help with Silverblue, it might be worth to provide logs of an affected boot. So boot your system the way it has the very issue, provoke whatever symptoms you know, and then provide, if possible both, of the following:
sudo journalctl --boot=-1 --no-hostname -k → kernel only
sudo journalctl --boot=-1 --no-hostname → all logs, its not always the kernel, feel free to remove/replace MAC/IP addresses, UUIDs, usernames, etc if you consider them private.

It is always useful to know in advance the output of cat /proc/sys/kernel/tainted → that can sometimes give already a hint what to look for in the logs :classic_smiley:

1 Like
15

Hi Chris,

thanks for your support und hints to investigate further.

I posted the result of the journalctl output in the following two links as it is too many characters for the forum post.

Kernel only messages
sudo journalctl --boot=-1 --no-hostname -k

Link

All messages
sudo journalctl --boot=-1 --no-hostname

Link

If I interpret the output correctly, there is nothing tainted in the kernel

cat /proc/sys/kernel/tainted

0

16

As mentioned, please just boot the system, provoke whatever issue you have, and then create the logs of that. What you posted contains a 10 hour boot :classic_smiley:

Assuming that the problem takes place during boot and thus before you put your system to sleep, I assume the actual issue (unintended behavior → everything takes too long) is between 13:55:06 and the first suspension on 13:56:51.

Can you detail your definition of slow? So, how long did your system take to boot up to the login screen before the update in question? And how long does it take now? Both in seconds? Can you also elaborate when exactly the delays take place. You said one delay takes place immediately before the login screen appears: what is on the screen at the very moment of this delay? How long is the exact delay? Your formulation indicates there is another delay moment before that: when does that take place, how long and what is on the screen at that moment?

If it is possible to complement your logs with exact times of when the delay(s) took place in the very boot, that would be great too.

17

Hi Steve,

I appreciate your support.

Frankly, I don’t feel competent enough to really well interpret the output of the plot.

Boot_Plot
Boot_Plot1000×971 142 KB

From my unterstanding and asking AI (for what this is worth) sys-module-fuse.service is giving headaches.

The kernel module for fuse is part of the initrd, so I should be able to rule out this possibility

sudo lsinitrd | grep fuse
[sudo] Passwort für pascal:
zstd: /*stdin*\: unsupported format
zstd: /*stdin*\: unsupported format
zstd: /*stdin*\: unsupported format
drwxr-xr-x   2 root     root            0 Jan  1  1970 usr/lib/modules/6.18.9-200.fc43.x86_64/kernel/fs/fuse
-rw-r--r--   1 root     root        19240 Jan  1  1970 usr/lib/modules/6.18.9-200.fc43.x86_64/kernel/fs/fuse/cuse.ko.xz
-rw-r--r--   1 root     root       141492 Jan  1  1970 usr/lib/modules/6.18.9-200.fc43.x86_64/kernel/fs/fuse/fuse.ko.xz
-rw-r--r--   1 root     root        33624 Jan  1  1970 usr/lib/modules/6.18.9-200.fc43.x86_64/kernel/fs/fuse/virtiofs.ko.xz
-rw-r--r--   2 root     root            0 Jan  1  1970 usr/lib/modules-load.d/fuse-overlayfs.conf
zstd: /*stdin*\: unsupported format

Checking what journalctl tells me about the kernel module and how it is loaded

journalctl -b -u modprobe@fuse.service
Feb 13 13:55:26 SilverFed systemd[1]: modprobe@fuse.service - Load Kernel Module fuse skipped, unmet condition check ConditionKernelModuleLoaded=!fuse

systemd-analyze blame | grep fuse
Feb 13 13:55:06 fedora kernel: fuse: init (API version 7.45)
Feb 13 13:55:06 fedora systemd-modules-load[326]: Inserted module 'fuse'
Feb 13 13:55:26 SilverFed systemd[1]: modprobe@fuse.service - Load Kernel Module fuse skipped, unmet condition check ConditionKernelModuleLoaded=!fuse
Feb 13 13:55:26 SilverFed systemd[1]: Mounting sys-fs-fuse-connections.mount - FUSE Control File System...
Feb 13 13:55:26 SilverFed systemd[1]: Mounted sys-fs-fuse-connections.mount - FUSE Control File System.
Feb 13 13:55:26 SilverFed systemd[1]: modprobe@fuse.service - Load Kernel Module fuse skipped, unmet condition check ConditionKernelModuleLoaded=!fuse

I noticed with systemd-analyze blame that TPM shows up.

TPM is not active in the BIOS settings, actually there is no option for TPM

In dmesg I cannot see anything noticeable timewise

sudo dmesg -T | grep -iE "tpm|wait|timeout"
[sudo] Passwort für pascal: 
[So Feb 15 14:28:43 2026] efi: ACPI=0x67118000 ACPI 2.0=0x67118014 TPMFinalLog=0x670e7000 SMBIOS=0x67b94000 SMBIOS 3.0=0x67b93000 MEMATTR=0x60fef698 ESRT=0x60ab8f18 MOKvar=0x67bd6000 RNG=0x66f92018 TPMEventLog=0x66f87018 
[So Feb 15 14:28:43 2026] ACPI: TPM2 0x0000000066F94000 00004C (v04 ALASKA A M I    00000001 AMI  00000000)
[So Feb 15 14:28:43 2026] ACPI: Reserving TPM2 table memory at [mem 0x66f94000-0x66f9404b]
[So Feb 15 14:28:43 2026] process: using mwait in idle threads
[So Feb 15 14:28:45 2026] Monitor-Mwait will be used to enter C-1 state
[So Feb 15 14:28:45 2026] Monitor-Mwait will be used to enter C-2 state
[So Feb 15 14:28:45 2026] Monitor-Mwait will be used to enter C-3 state
[So Feb 15 14:28:45 2026] systemd[1]: systemd 258.4-1.fc43 running in system mode (+PAM +AUDIT +SELINUX -APPARMOR +IMA +IPE +SMACK +SECCOMP -GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +BTF +XKBCOMMON +UTMP +SYSVINIT +LIBARCHIVE)
[So Feb 15 14:28:45 2026] systemd[1]: systemd-pcrphase-initrd.service - TPM PCR Barrier (initrd) skipped, unmet condition check ConditionSecurity=measured-uki
[So Feb 15 14:29:00 2026] systemd[1]: systemd 258.4-1.fc43 running in system mode (+PAM +AUDIT +SELINUX -APPARMOR +IMA +IPE +SMACK +SECCOMP -GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +BTF +XKBCOMMON +UTMP +SYSVINIT +LIBARCHIVE)
[So Feb 15 14:29:01 2026] systemd[1]: systemd-pcrextend.socket - TPM PCR Measurements skipped, unmet condition check ConditionSecurity=measured-uki
[So Feb 15 14:29:01 2026] systemd[1]: systemd-pcrlock.socket - Make TPM PCR Policy skipped, unmet condition check ConditionSecurity=measured-uki
[So Feb 15 14:29:01 2026] systemd[1]: systemd-pcrmachine.service - TPM PCR Machine ID Measurement skipped, unmet condition check ConditionSecurity=measured-uki
[So Feb 15 14:29:01 2026] systemd[1]: systemd-tpm2-setup-early.service - Early TPM SRK Setup skipped, unmet condition check ConditionSecurity=measured-uki
[So Feb 15 14:29:03 2026] Bluetooth: hci0: Waiting for firmware download to complete
[So Feb 15 14:29:03 2026] Bluetooth: hci0: Waiting for device to boot

Interestingly ls /sys/class/tpm/ gives tpm0 as output

Maybe my system waits for a tpm-chips which actually is not active?

18

Hi Chris,

my apologies, I posted output of yesterday’s boot process, thus the 10 hour time delay. The system wasn’t put to sleep. And thanks for your patience with me.

I try to explain my pain points with booting.

Grub entries appear very quickly (5 seconds after pressing the physical power-on button), the entry field for the LUKS passphrase is also visible without any major delay - again 3 seconds. The following boot process until the graphical login screen for the user is shown takes between 19-30 seconds (this varies from boot to boot). After entering the passphrase the screen remains blank. The boot process took about 4-5 seconds after the passphrase with the freshly installed system without any updates or modifications (like setting up distrobox and layering some packages - see previous output of rpm-ostree status)

Short overview of the time it takes according to systemd

systemd-analyze blame

32.879s sys-module-fuse.device
32.708s dev-tpm0.device
32.708s sys-devices-LNXSYSTM:00-LNXSYBUS:00-MSFT0101:00-tpm-tpm0.device

The output of sudo journalctl --boot=-1 --no-hostname for the current boot process you can find here: (too long to post here)

The kernel messages are here:

sudo journalctl --boot=-1 --no-hostname -k

Feb 15 20:26:23 kernel: rfkill: input handler enabled
Feb 15 20:26:25 kernel: rfkill: input handler disabled
Feb 15 20:28:24 kernel: evm: overlay not supported
Feb 15 20:28:45 kernel: wlo1: disconnect from AP 04:b4:fe:03:bd:1c for new auth to 04:b4:fe:03:bd:1b
Feb 15 20:28:45 kernel: wlo1: authenticate with 04:b4:fe:03:bd:1b (local address=32:57:76:81:a6:f1)
Feb 15 20:28:45 kernel: wlo1: send auth to 04:b4:fe:03:bd:1b (try 1/3)
Feb 15 20:28:45 kernel: wlo1: authenticated
Feb 15 20:28:45 kernel: wlo1: associate with 04:b4:fe:03:bd:1b (try 1/3)
Feb 15 20:28:45 kernel: wlo1: RX ReassocResp from 04:b4:fe:03:bd:1b (capab=0x1411 status=0 aid=27)
Feb 15 20:28:45 kernel: wlo1: associated
Feb 15 20:28:45 kernel: wlo1: Limiting TX power to 20 (20 - 0) dBm as advertised by 04:b4:fe:03:bd:1b
Feb 15 20:29:00 kernel: wlo1: disconnect from AP 04:b4:fe:03:bd:1b for new auth to 04:b4:fe:03:bd:1c
Feb 15 20:29:00 kernel: wlo1: authenticate with 04:b4:fe:03:bd:1c (local address=32:57:76:81:a6:f1)
Feb 15 20:29:00 kernel: wlo1: send auth to 04:b4:fe:03:bd:1c (try 1/3)
Feb 15 20:29:00 kernel: wlo1: authenticated
Feb 15 20:29:00 kernel: wlo1: associate with 04:b4:fe:03:bd:1c (try 1/3)
Feb 15 20:29:00 kernel: wlo1: RX ReassocResp from 04:b4:fe:03:bd:1c (capab=0x1011 status=0 aid=19)
Feb 15 20:29:00 kernel: wlo1: associated
Feb 15 20:29:00 kernel: wlo1: Limiting TX power to 23 (23 - 0) dBm as advertised by 04:b4:fe:03:bd:1c
19

According to your first logs, your system was put to sleep in that boot process, and kept asleep for about 5 hours:

Feb 13 13:56:51 systemd-sleep[6895]: Successfully froze unit 'user.slice'.
Feb 13 13:56:51 systemd-sleep[6895]: Performing sleep operation 'suspend'...
Feb 13 13:56:51 kernel: PM: suspend entry (s2idle)
Feb 13 13:56:51 kernel: Filesystems sync: 0.017 seconds
Feb 13 18:54:57 kernel: Freezing user space processes

If you are sure it was not, these logs indicate an issue, but I have to admit, I tend to assume these entries are reliable :classic_smiley:

That’s again a long log of 36 minutes, but it’s ok to skim. I don’t think it is the cause of your problem, what it makes me wonder that your clock has been massively adjusted during the test?

Feb 07 01:00:44 chronyd[1389]: Selected source 192.168.178.1 (_gateway)
Feb 07 01:00:44 chronyd[1389]: System clock wrong by 760985.103617 seconds
Feb 15 20:23:49 systemd-resolved[1325]: Clock change detected. Flushing caches.
Feb 15 20:23:49 chronyd[1389]: System clock was stepped by 760985.103617 seconds
Feb 15 20:23:49 chronyd[1389]: System clock TAI offset set to 37 seconds

Formally, the boot started at exact 01:00:00.

Can you try to unplug everything that is attached by USB and then try again? I ask because of the time delay’s that occur here:

Feb 07 01:00:02 kernel: typec port0: bound usb4_port1 (ops connector_ops [thunderbolt])
Feb 07 01:00:04 kernel: usb 3-2.3.2: New USB device found, idVendor=046d, idProduct=0843, bcdDevice= 0.13
Feb 07 01:00:04 kernel: usb 3-2.3.2: New USB device strings: Mfr=0, Product=2, SerialNumber=1
Feb 07 01:00:04 kernel: usb 3-2.3.2: Product: Logitech Webcam C930e
Feb 07 01:00:04 kernel: usb 3-2.3.2: SerialNumber: 4DADC45E
Feb 07 01:00:15 kernel: usb 3-4: new full-speed USB device number 10 using xhci_hcd
Feb 07 01:00:15 kernel: usb 3-4: New USB device found, idVendor=3434, idProduct=0661, bcdDevice= 1.00
Feb 07 01:00:15 kernel: usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Feb 07 01:00:15 kernel: usb 3-4: Product: Keychron Q6 Pro
Feb 07 01:00:15 kernel: usb 3-4: Manufacturer: Keychron
Feb 07 01:00:15 kernel: input: Keychron Keychron Q6 Pro as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0/0003:3434:0661.0005/input/input15
Feb 07 01:00:15 kernel: hid-generic 0003:3434:0661.0005: input,hidraw4: USB HID v1.11 Keyboard [Keychron Keychron Q6 Pro] on usb-0000:00:14.0-4/input0
Feb 07 01:00:15 kernel: hid-generic 0003:3434:0661.0006: hiddev98,hidraw5: USB HID v1.11 Device [Keychron Keychron Q6 Pro] on usb-0000:00:14.0-4/input1
Feb 07 01:00:15 kernel: input: Keychron Keychron Q6 Pro Mouse as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.2/0003:3434:0661.0007/input/input16
Feb 07 01:00:15 kernel: input: Keychron Keychron Q6 Pro System Control as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.2/0003:3434:0661.0007/input/input17
Feb 07 01:00:15 kernel: input: Keychron Keychron Q6 Pro Consumer Control as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.2/0003:3434:0661.0007/input/input18
Feb 07 01:00:15 kernel: input: Keychron Keychron Q6 Pro Keyboard as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.2/0003:3434:0661.0007/input/input19
Feb 07 01:00:15 kernel: hid-generic 0003:3434:0661.0007: input,hidraw6: USB HID v1.11 Mouse [Keychron Keychron Q6 Pro] on usb-0000:00:14.0-4/input2
Feb 07 01:00:27 systemd-cryptsetup[636]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/4a3d4c2d-6b91-4543-be49-ef9c869f3dcd.
Feb 07 01:00:31 systemd[1]: Found device dev-disk-by\x2duuid-8b3be73f\x2d77bd\x2d4dc0\x2d9efd\x2dd1578d945c55.device - /dev/disk/by-uuid/8b3be73f-77bd-4dc0-9efd-d1578d945c55.
Feb 07 01:00:31 systemd[1]: Finished systemd-cryptsetup@luks\x2d4a3d4c2d\x2d6b91\x2d4543\x2dbe49\x2def9c869f3dcd.service - Cryptography Setup for luks-4a3d4c2d-6b91-4543-be49-ef9c869f3dcd.
Feb 07 01:00:31 systemd[1]: Reached target cryptsetup.target - Local Encrypted Volumes.

I could imagine these are your 30 seconds?

I did not read everything of the 36 minutes, but the term “fuse” seems to not occur at the time the delay occurs, and the time the delays in the logs occur correspond to your elaborations about when it occurs.

This is not a solution per se. But I think it tells us where to focus on. But again: this can itself be a symptom of an earlier cause. But it’s something worth to analyze.

It might be useful to compare: you say that the issue came after an update. However, have you ever tested to revert? So if you know boot your earlier Silverblue image from before the update, does it still boot fast without the delay? Is that 100% reproducible? Old image → quick boot and new image → <=30 sec delay? If so, it might be useful to compare a log of both…

You might also check out the log lines of the time of the delay in your preferred search engine and see if others link these lines to comparable phenomena.

Maybe someone has also time to analyze these logs in depth but that might take some time :classic_smiley:

20

I’ve had to debug a similar issue recently and it was helpful to use the short-delta flag for journalctl to better see which steps take longer.

journalctl --boot=0 --output=short-delta | grep --invert-match '< *0.'

Should help you ignore everything that takes up less than a second, ideally run as soon as you’ve booted the machine up.

In my case the issue was with older harder that didn’t support tpm but systemd was still waiting for two tpm services to timeout (with a 30 seconds default timeout that added up). In my case this also wasn’t easily noticeable via systemd-analyze.

2 Likes
21

Hi Chris,

chapeau for your awareness of details!!!

Looks like you are spot on with attached USB to be culprit.

First of all,

I booted the initial pristine deployment and the latest one without any USB attached (normally I use an external cable mouse)

For both scenarios the exactly same boot duration, checked with a stopwatch

LUKS passphrase entry field appears only 3 seconds after GRUB entries, then another 7 seconds until the graphical user login. To me this seems quite Ok as boot time, so no issues here.

When I have the mouse attached or even charging the laptop with a USB-cable the boot delay kicks in. In the latest try it was even 49 seconds until the LUKS passphrase after GRUB and a whopping 1 minute 38 seconds until the graphical login.

Here are the different journalctl logs with USB and without - some logs are from this afternoon CET local time, therefor the differences in the time stamps

journalctl --no-hostname -b 0 -k with USB attached: JOURNALCTLKernelUSB - Pastes.io (this evening)

journalctl --no-hostname -b 0 -k without USB: JOURNALKernelNOUSB - Pastes.io (this afternoon)

journalctl --no-hostname -b 0 with USB attached: https://pastes.io/journal_us (this evening)

journalctl --no-hostname -b 0 without USB: https://pastes.io/journalnou (this afternoon)