Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ubuntu 22.04 vs ZFS = hung boot #417

Open
JonTheNiceGuy opened this issue Apr 28, 2023 · 1 comment
Open

Ubuntu 22.04 vs ZFS = hung boot #417

JonTheNiceGuy opened this issue Apr 28, 2023 · 1 comment

Comments

@JonTheNiceGuy
Copy link

  • Are you using the latest driver? Version from Apt repo (5.7.0-129)
  • Are you using the latest EVDI version? Version from Apt repo (1.13.1-18)
  • If you are using a DisplayLink device, have you checked 'troubleshooting'
    on DisplayLink's website? Not listed
  • Is this issue related to evdi/kernel? Not... necessarily!
  • Linux distribution and its version : Ubuntu 22.04
  • Linux kernel version: 5.19.0-41-generic #42~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Apr 18 17:40:00 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
  • Xorg version (if used): ii xorg 1:7.7+23ubuntu2 amd64 X.Org X Window System
  • Desktop environment in use: Ubuntu Gnome

Following the installation of the above package and rebooting, I was presented with a recovery console.

Purging the displaylink-driver and evdi packages restores my machine to it's former state, but this isn't really useful.

Following re-installing the driver, rebooting and returning to the recovery console, when digging into the logs, I found an entry showing that:

Apr 28 11:12:05 jonspriggs-Kratos-EL04R6 systemd[1]: Starting Wait for udev To Complete Device Initialization...
░░ Subject: A start job for unit systemd-udev-settle.service has begun execution
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░ 
░░ A start job for unit systemd-udev-settle.service has begun execution.
░░ 
░░ The job identifier is 20.

Followed later by

Apr 28 11:13:05 jonspriggs-Kratos-EL04R6 systemd-udevd[1912]: 4-3.1.3:1.0: Spawned process '/opt/displaylink/udev.sh /dev /devices/pci0000:00/0000:00:14.0/usb4/4-3/4-3.1/4-3.1.3/4-3.1.3:1.0 usb-004-004-DisplayLink_PR09_DisplayPort_Dock_YVFJ093338 /dev/bus/usb/004/004' [2280] is taking longer than 59s to complete
Apr 28 11:13:05 jonspriggs-Kratos-EL04R6 systemd-udevd[1787]: 4-3.1.3:1.0: Worker [1912] processing SEQNUM=4598 is taking a long time
Apr 28 11:14:05 jonspriggs-Kratos-EL04R6 systemd[1]: systemd-udev-settle.service: Main process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░ 
░░ An ExecStart= process belonging to unit systemd-udev-settle.service has exited.
░░ 
░░ The process' exit code is 'exited' and its exit status is 1.

Manually running the above command did not take a long time (in fact, it ran and completed in microseconds).

In some of the intervening logs, I also saw:

Apr 28 11:12:05 jonspriggs-Kratos-EL04R6 udevadm[1890]: systemd-udev-settle.service is deprecated. Please fix zfs-load-module.service, zfs-import-cache.service not to pull it in.

Correspondingly, I have adjusted the zfs-load-module.service (/lib/systemd/system/zfs-load-module.service) and zfs-import-cache.service (/lib/systemd/system/zfs-import-cache.service) files, commenting out Requires=systemd-udev-settle.service, which has worked-around this issue.

I concede that the ZFS services shouldn't depend on systemd-udev-settle, however, the fact that systemd-udev-settle is failing as a result of the DisplayLink or evdi service means that it's having a knock-on impact on other areas of the system.

Please can you investigate?

@nickk-acc
Copy link

nickk-acc commented Sep 23, 2024

I have the exact same problem on my laptop!

And I know at least one other person that said to me that his laptop boots really slow but he did not really care why since it always booted. I had checked and he also used ubuntu+2 displaylink monitors through a dock.

The problem does not happen if the monitor connects directly to the pc (I have an exact same os and monitor on a tower). It seems to only happens when the monitors are connected to a dock.

The problem also goes away without any changes to the .services files if during boot you disconnect the dock from the pc and connect it after the boot (what I have been doing).

Edit: Also tried with commenting out the "Requires=systemd-udev-settle.service" from the .services and worked. Thank you @JonTheNiceGuy ! No more connecting and disconnecting the dock at last!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants