Long boot time on Fedora 38 (initrd taking the longest time)

Ask Fedora
1

Hi everyone,

This is my first time using Fedora and I have just managed to install it (dualboot) after running into a few issues and now the system is running just fine.

There’s one thing that’s bothering me, though, and it’s the boot time. After I choose to boot Fedora, it takes a long time to get to the log-in screen and it shouldn’t be expected since I am booting it from an SSD.

When I run systemd-analyze, this is what I get:

image
image809×97 10.8 KB

Then I run systemd-analyze blame and this is the result:

image
image980×997 33.8 KB

When I run systemd-analyze blame | head

image
image744×346 11.1 KB

I have went through other discussions regarding long boot times on Fedora, but they show different component taking a long time, while in my case there are several components taking 1+ minute, so I don´t really know what to do in this case. Does anyone know how to solve it?

2

Note that the 1+ minute you show are not a per-line time, but a total accumulated time when that line item starts.

The output of systemd-analyze critical-chain may give one a better idea of the stage which is causing the delay.

In the future please post all text (as much as possible) using copy and paste to put the text directly into the post. It can be made to retain the on-screen formatting by using the Preformatted text tags available with the </> button on the toolbar, or by bracketing the text with ``` (triple back-quote) on the lines preceding and following the actual text.

1 Like
3

Thanks for your advice, I will do that in the future.

This is the output from 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 @10.417s
└─multi-user.target @10.417s
  └─plymouth-quit-wait.service @8.403s +1.997s
    └─systemd-user-sessions.service @8.353s +29ms
      └─remote-fs.target @8.339s
        └─remote-fs-pre.target @8.339s
          └─nfs-client.target @2.847s
            └─gssproxy.service @2.288s +9ms
              └─network.target @2.285s
                └─wpa_supplicant.service @9.683s +8ms
                  └─dbus-broker.service @2.047s +15ms
                    └─dbus.socket @2.000s
                      └─sysinit.target @1.998s
                        └─systemd-resolved.service @1.933s +64ms
                          └─systemd-tmpfiles-setup.service @1.875s +46ms
                            └─import-state.service @1.817s +36ms
                              └─local-fs.target @1.816s
                                └─run-credentials-systemd\x2dtmpfiles\x2dsetup.service.mount @2.794s
                                  └─local-fs-pre.target @1.018s
                                    └─systemd-tmpfiles-setup-dev.service @940ms +78ms
                                      └─kmod-static-nodes.service @729ms +88ms
                                        └─systemd-journald.socket
                                          └─system.slice
                                            └─-.slice

The lines

plymouth-quit-wait.service @8.403s +1.997s
systemd-user-sessions.service @8.353s +29ms
[...]
gssproxy.service @2.288s +9ms
[...]
wpa_supplicant.service @9.683s +8ms
dbus-broker.service @2.047s +15ms
[...]
systemd-resolved.service @1.933s +64ms
systemd-tmpfiles-setup.service @1.875s +46ms
import-state.service @1.817s +36ms
[...]
systemd-tmpfiles-setup-dev.service @940ms +78ms
kmod-static-nodes.service @729ms +88ms

are all in red.

EDIT: I ran the command systemd-analyze plot > bootchart.svg and I have uploaded the .svg file to Google Drive

4

According to the critical-chain the boot completed at about 10 seconds.

The lines in red are ones for which (some of) the following lines must wait for completion

According to the plotted chart it took about 1 min 16 sec to configure devices. Are you sure both those are the same system and the same boot? Times do not seem to match. The plot shows graphical target and boot completed at about 88 seconds.

In any case, is there a difference between doing a restart vs. a cold boot?

I don’t understand why device config would require that much time in most cases.

5

I run all three commands (systemd-analyze, systemd-analyze critical-chain and systemd-analyze plot > bootchart.svg) after both a restart and a cold boot. Here are the logs:

Cold boot

systemd-analyze
Startup finished in 22.709s (firmware) + 4.936s (loader) + 4.418s (kernel) + 1min 16.687s (initrd) + 8.177s (userspace) = 1min 56.929s 
graphical.target reached after 4.309s 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 @4.309s
└─multi-user.target @4.309s
  └─plymouth-quit-wait.service @2.264s +2.027s
    └─systemd-user-sessions.service @2.247s +14ms
      └─remote-fs.target @2.245s
        └─remote-fs-pre.target @2.245s
          └─nfs-client.target @2.245s
            └─gssproxy.service @2.235s +9ms
              └─network.target @2.232s
                └─wpa_supplicant.service @3.559s +9ms
                  └─dbus-broker.service @1.950s +15ms
                    └─dbus.socket @1.904s
                      └─sysinit.target @1.902s
                        └─systemd-resolved.service @1.830s +71ms
                          └─systemd-tmpfiles-setup.service @1.760s +51ms
                            └─import-state.service @1.698s +31ms
                              └─local-fs.target @1.697s
                                └─run-credentials-systemd\x2dresolved.service.mount @1.868s
                                  └─local-fs-pre.target @847ms
                                    └─systemd-tmpfiles-setup-dev.service @810ms +37ms
                                      └─kmod-static-nodes.service @627ms +62ms
                                        └─systemd-journald.socket
                                          └─system.slice
                                            └─-.slice

Link to .svg file.

Restart

systemd-analyze
Startup finished in 22.718s (firmware) + 3.524s (loader) + 4.443s (kernel) + 1min 16.548s (initrd) + 8.154s (userspace) = 1min 55.389s 
graphical.target reached after 4.402s in userspace.

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 @4.402s
└─multi-user.target @4.402s
  └─plymouth-quit-wait.service @2.339s +2.045s
    └─systemd-user-sessions.service @2.314s +13ms
      └─remote-fs.target @2.313s
        └─remote-fs-pre.target @2.313s
          └─nfs-client.target @2.313s
            └─gssproxy.service @2.303s +9ms
              └─network.target @2.300s
                └─wpa_supplicant.service @3.659s +4ms
                  └─dbus-broker.service @2.030s +15ms
                    └─dbus.socket @1.988s
                      └─sysinit.target @1.986s
                        └─systemd-resolved.service @1.915s +70ms
                          └─systemd-tmpfiles-setup.service @1.840s +53ms
                            └─import-state.service @1.774s +40ms
                              └─local-fs.target @1.774s
                                └─run-user-1000-gvfs.mount @7.982s
                                  └─run-user-1000.mount @6.821s
                                    └─swap.target @1.132s
                                      └─dev-zram0.swap @1.103s +29ms
                                        └─systemd-zram-setup@zram0.service @1.033s +56ms
                                          └─dev-zram0.device @1.015s

Link to .svg file.

6

I am not able to guess at the timing. Both of the plot outputs show an excessive amount of time required for config of the hardware even though the ‘blame’ and ‘critical-chain’ do not reflect the delay. Now the logs from journalctl -b are going to be needed to try and identify the cause.

I suggest that as soon as the boot completes you run the command above and post it so we may see the details. Since that is taking over a minute to complete the start we may be able to suggest a fix once the details are available.

I am suspecting that there are some delays involved in trying to load drivers that may be failing and there is a timeout required for that.

I also suggest that before you do the next boot that you explicitly do a full upgrade with dnf upgrade --refresh and also post the output of inxi -Fzxx

7

I was having the same discussion on Reddit and an user also suggested to run journalctl -b to find out more about it. And it actually helped, I managed to fix this issue (even though I don’t actually understand why and how). Here’s what happened:

After running journalctl -b, I found these errors:

ago 03 13:16:39 fedora kernel: usb 1-8: device descriptor read/64, error -110
ago 03 13:16:55 fedora kernel: usb 1-8: device descriptor read/64, error -110
ago 03 13:16:55 fedora kernel: usb 1-8: new full-speed USB device number 6 using xhci_hcd
ago 03 13:17:11 fedora kernel: usb 1-8: device descriptor read/64, error -110
ago 03 13:17:24 fedora systemd-udevd[425]: usb1: Worker [444] processing SEQNUM=1822 is taking a long time
ago 03 13:17:27 fedora kernel: usb 1-8: device descriptor read/64, error -110
ago 03 13:17:27 fedora kernel: usb usb1-port8: attempt power cycle
ago 03 13:17:27 fedora kernel: usb 1-8: new full-speed USB device number 7 using xhci_hcd
ago 03 13:17:32 fedora kernel: usb 1-8: Device not responding to setup address.
ago 03 13:17:32 fedora kernel: usb 1-8: Device not responding to setup address.
ago 03 13:17:33 fedora kernel: usb 1-8: device not accepting address 7, error -71
ago 03 13:17:33 fedora kernel: usb 1-8: new full-speed USB device number 8 using xhci_hcd
ago 03 13:17:38 fedora kernel: usb 1-8: Device not responding to setup address.
ago 03 13:17:38 fedora kernel: usb 1-8: Device not responding to setup address.
ago 03 13:17:38 fedora kernel: usb 1-8: device not accepting address 8, error -71
ago 03 13:17:38 fedora kernel: usb usb1-port8: unable to enumerate USB device
ago 03 13:17:38 fedora kernel: usb 1-10: new full-speed USB device number 9 using xhci_hcd

Then I run lsusb to check for these devices:

Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 05ac:024f Apple, Inc. Aluminium Keyboard (ANSI)
Bus 001 Device 003: ID 046d:08e3 Logitech, Inc. C505 HD Webcam
Bus 001 Device 002: ID 046d:c539 Logitech, Inc. Lightspeed Receiver
Bus 001 Device 009: ID 048d:5702 Integrated Technology Express, Inc. RGB LED Controller
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I did some troubleshooting on these devices. Four of them I believe to be the actual USB ports (the “Linux Foundation X.0 root hub” ones) and the rest are my peripherals (keyboard, USB receiver for wireless mouse, Webcam and Bluetooth USB adapter) connected to those ports

  1. I unplugged the non-essential ones (Webcam and Bluetooth adapter) and rebooted. This basically solved the issue, since the reboot was way quicker (after I run systemd-analyze it logged about 25-28s in total).

  2. I plugged in only the Webcam. Rebooted. Same quicker reboot.

  3. I unplugged the Webcam and plugged in the BT adapter. Rebooted. Same quicker reboot.

  4. Finally I plugged back in the Webcam. Rebooted. Same…

Just to make sure, I also did a cold boot instead of a reboot. It was also fairly quick. It’s now taking about 27s to boot. It’s not the quickest but it’s a lot better than taking about 2 minutes to boot.

As I said, I don’t really know what was going wrong nor why just rebooting with only one of them plugged in at a time (apparently) solved the issue.

Now, when I run journalctl -b, there are no errors related to USB devices, although there are still a few other errors that I will try to solve.

This is the link to the discussion, in case anyone wants to read it in full.

8

I failed to suggest disconnect of any exteral devices that are non-critical while troubleshooting. My error.

Glad it was figured out and now things are working well.

It appears the issue was causing the delay in device configs, though it did not show up by the normal expected systemd-analyze commands as one would expect.