fwupd service is slowing the boot time on my PCIe SSD. Why is it doing that, and how can I fix it?

Question

My system is currently showing some strange behavior on boot. The GUI login appears seconds after hitting the power button, but my keyboard and mouse remain unpowered for about a minute. systemd-analyze indicates fwupd.service is the problem:

$ systemd-analyze time
Startup finished in 12.573s (firmware) + 293ms (loader) + 3.710s (kernel) + 1min 2.907s (userspace) = 1min 19.485s 
graphical.target reached after 5.434s in userspace

$ systemd-analyze blame
1min 705ms fwupd.service                       
    4.083s plymouth-quit-wait.service          
    1.028s gpu-manager.service                 
     925ms systemd-logind.service              
     708ms systemd-resolved.service            
     507ms accounts-daemon.service             
     490ms networkd-dispatcher.service         
     488ms system76-power.service              
     470ms fancontrol.service                  
     437ms ModemManager.service                
     301ms systemd-journald.service
...

journalctl -u indicates that fwupd is getting hung up on some device:

Jun 25 21:25:49 pop_os systemd[1]: Starting Firmware update daemon...
Jun 25 21:25:50 pop_os fwupd[1501]: 01:25:50:0156 FuPluginUefi         failed to add /sys/firmware/efi/esrt/entries/entry0: ESRT GUID '00000000-0000-0000-0000-000000000000' was not valid
Jun 25 21:26:50 pop_os systemd[1]: Started Firmware update daemon.

I tried putting the specified GUID of 00000000-0000-0000-0000-000000000000 in the BlacklistDevices variable in /etc/fwupd/daemon.conf, but that had no effect on the boot time. I also looked in the /sys/firmware/efi/esrt/entries/entry0 directory, and the file fw_class in that directory contained the above GUID.

Here is the output of fwupdmgr get-devices:

$ fwupdmgr get-devices 
To Be Filled By O.E.M.
│
├─PCIe SSD:
│     Device ID:           71b677ca0f1bc2c5b804fa1d59e52064ce589293
│     Summary:             NVM Express Solid State Drive
│     Current version:     ECFM12.3
│     Vendor:              Phison Electronics Corporation (NVME:0x1987)
│     GUIDs:               8cb1e2fe-eb01-5508-9fb3-98add4bb7c34
│                          a44eb54c-5441-56f2-8cc0-5e48964c6457
│                          8d128eab-f266-513f-81e7-910de65fd73a
│     Device Flags:        • Internal device
│                          • Updatable
│                          • Requires AC power
│                          • Supported on remote server
│                          • Needs shutdown after installation
│                          • Device is usable for the duration of the update
│   
└─PS Audio USB Audio 2.0:
      Device ID:           aff287d984fc4f1ed8f1ab3b35e4650b1b1f6c22
      Current version:     6.152
      Vendor:              PS Audio (USB:0x2616)
      GUIDs:               0f7b0016-25d6-5bc5-a6e0-423dba203c62
                           1fd717ad-32ef-5d86-a59a-71fd73ed6aae
      Device Flags:        • Updatable

My understanding here is that fwupd.service is getting hung up on this ESRT GUID entry for a whole minute before giving up and moving on. My question is: What the heck is that entry, and how can I stop it from slowing down my boot?

Edit: It turns out that it was not fwupd at all, but rather the Xbox One wireless adapter that was slowing everything down. Booting without the adapter plugged in completely solves the problem.

telcoM · Accepted Answer · 2020-06-26T05:46:27.143

3

Short answer: your system's UEFI firmware claims to support the "UEFI firmware update capsule" mechanism that allows an unified way for all operating systems to provide system firmware updates (also known as "BIOS updates"). But your current firmware version apparently provides a null GUID in the ESRT information table instead of properly identifying the updateable system firmware, so the attempt to check whether or not newer firmware versions are available at Linux Vendor Firmware Service is failing.

The name of the fwupd plugin responsible for reading the ESRT information table from the system firmware and querying for the availability of that type of firmware update is uefi, so you might try editing the BlacklistPlugins line in your /etc/fwupd/daemon.conf to:

BlacklistPlugins=test;uefi

(assuming that your configuration file already includes default blacklisting for the test plugin, like it does on my Debian 10)

The fwupd.service is entirely optional, so it should be no problem to disable it altogether (with systemctl mask fwupd.service to prevent it auto-starting even if other services request it), if you prefer that solution. But then you'll need to find any firmware updates applicable to your system yourself, in the old-fashioned way. :-)

With luck, the system vendor may have fixed it in an updated UEFI firmware version, so updating your UEFI firmware to the latest available version just might fix the problem.

edited Jun 26 '20 at 05:46

answered Jun 26 '20 at 05:39

telcoM

96,466

Thanks! Now I understand what I'm dealing with a little bit better.
Unfortunately, neither blacklisting the uefi plugin nor masking fwupd.service seems to solve my keyboard/mouse woes. I have confirmed with systemd-analyze blame that fwupd.service is not running at boot. However, USB devices still remain unpowered for roughly a minute after I reach the graphical login screen.

Regardless, thanks to you, I know that fwupd is NOT the culprit. I'll investigate some other possibilities and ask a new question once I know more.
– Brandon Smith Jun 26 '20 at 14:12
1

Yes. After a second look at your log timestamps (insufficient caffeination error on my part the first time?) it is obvious that the ESRT null GUID causes a very quick failure, but something causes a significant pause with the USB subsystem. Do you have USB Type-C connections on your system? Are the modules to support it (lsmod | grep -e typec -e ucsi) getting loaded too late, which might explain the pause? Anything else special in your USB hardware? – telcoM Jun 26 '20 at 14:20
Yes, there is a rear USB C connection on the motherboard. Nothing is currently connected to it, and lsmod is showing zero matches for typec and ucsi. Would those modules being missing potentially cause this pause? As for USB hardware, I have a keyboard with QMK firmware, Logitech Powerplay mouse mat with G703 mouse, USB DAC/AMP combo, Xbox One wireless controller adapter, and a 2-port USB 3.0 hub via my monitor. Nothing is connected to the hub at the moment. – Brandon Smith Jun 26 '20 at 14:43
I figured it out! It was the Xbox One wireless adapter. I'm not entirely sure why, but having it plugged in at boot was holding back ALL USB devices. When I boot without it plugged in, everything works great and I'm at the desktop in seconds. – Brandon Smith Jun 27 '20 at 15:54
That's odd. If you want to experiment further... if you let the system to start normally with the wireless adapter unplugged, then plug it in later, will it cause a similar pause? Also, if you check the dmesg output before and after plugging in the wireless adapter, are there any interesting messages? – telcoM Jun 27 '20 at 22:16

fwupd service is slowing the boot time on my PCIe SSD. Why is it doing that, and how can I fix it?

1 Answers1

Linked