QA » openQA Project » openQA Infrastructure

The service is indeed pulled by wickedd.service:

Wants=wickedd-nanny.service wickedd-dhcp6.service wickedd-dhcp4.service wickedd-auto4.service systemd-udev-settle.service

From man page of systemd-udev-settle.service:

It is a crude way to wait until "all" hardware has been discovered.

Using this service is not recommended.

So it is the way how wickedd ensures all available network hardware was discovered. The service can be probably safely masked (which I did to remedy this issue) as it is really needed when LVM is involved (and even that might no longer be true). In case of a problem, we need to modify the wickedd.service and wait explicitly wait for correct interfaces.

However, the issue itself (failing systemd-udev-settle.service) is caused by something else.
From the journal logs:

Feb 13 03:46:40 storage systemd-udevd[705]: sr0: Worker [749] processing SEQNUM=12763 is taking a long time
Feb 13 03:47:38 storage systemd[1]: systemd-udev-settle.service: Main process exited, code=exited, status=1/FAILURE
Feb 13 03:47:38 storage systemd[1]: systemd-udev-settle.service: Failed with result 'exit-code'.
Feb 13 03:47:38 storage systemd[1]: Failed to start Wait for udev To Complete Device Initialization.

The problem is in the /dev/sr0 device

Feb 13 03:45:40 storage kernel: scsi 19:0:0:0: CD-ROM            ATEN     Virtual CDROM    YS0J PQ: 0 ANSI: 0 CCS
Feb 13 03:45:40 storage kernel: scsi 19:0:0:0: Attached scsi generic sg13 type 5
Feb 13 03:45:40 storage kernel: sr 19:0:0:0: [sr0] scsi3-mmc drive: 40x/40x cd/rw xa/form2 cdda tray
Feb 13 03:45:40 storage kernel: cdrom: Uniform CD-ROM driver Revision: 3.20
Feb 13 03:45:40 storage kernel: sr 19:0:0:0: Attached scsi CD-ROM sr0

The problem is, that udev is also trying to probe this device, which will fail (as seen above). It can be confirmed with blkid /dev/sr0 which will hang for 5 minutes which is way beyond the default limit in udev. (The default value is 120 seconds as can be found in man page for udevadm).

There are 2 possible solutions for this:

1. Mask the systemd-udev-settle.service unit and not call udevadm settle during the boot explicitly (the chosen solution).
2. Edit the timeout for udev to at least 300 seconds to be able to probe /dev/sr0. This will also delay the boot for the same amount as the wickedd.service is waiting for that device.
3. Fix / remove the misbehaving device as it is probably just an attached virtual CD-ROM drive without media.

I assume you set it to "Resolved" by mistake because you evaluated options but haven't stated a resolution yet. I would favor option 3 but also like openSUSE packages to improve. So maybe still report a bug to wicked?

ah, ok. Then, well, resolved. I missed the part that you actually masked the service then.