Bug 1795014 - dmraid-activation.service drags in deprecated systemd-udev-settle.service, increases boot time
Summary: dmraid-activation.service drags in deprecated systemd-udev-settle.service, in...
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: dmraid
Version: 32
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Heinz Mauelshagen
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2020-01-26 12:17 UTC by Chris Murphy
Modified: 2020-04-30 17:48 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Type: Bug

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1796437 None None None 2020-01-31 16:31:12 UTC

Internal Links: 1796437

Description Chris Murphy 2020-01-26 12:17:22 UTC
Description of problem:

dmraid-activation.service drags in deprecated systemd-udev-settle.service, which increases boot times by 1-3 seconds.

Version-Release number of selected component (if applicable):

How reproducible:
Always, every boot

Steps to Reproduce:
1. Clean install Fedora Workstation 32/Rawhide, reboot

Actual results:

Longer boot times as a result of depending on udev-settle service.

$ systemctl list-dependencies dmraid-activation.service 
● ├─system.slice
● └─systemd-udev-settle.service

vendor preset: enabled

Expected results:

a. It shouldn't depend on udev-settle.service
b. The vendor preset probably should be disabled; anyone who needs this can start/enabled it.

Additional info:

Comment 1 Hans de Goede 2020-02-01 23:08:00 UTC
We have been discussing at least disabling the dmraid service by default in bug 1796437. Let me copy and paste a few relevant bits from there for further discussion here:

In bug 1796437 Chis Murphy wrote:

But even if dmraid-activation.service is fixed to no longer drag in udev-settle, I wonder whether dmraid-activation.service "is-enabled" being set to enabled/disabled is appropriate. Disabling things should be fail safe. Users shouldn't be able to disable a startup critical service and then end up abandoned on a deserted island. Should it be static and maybe have a generator conditionally trigger it instead?

I have no idea how expensive it is to search for dmraid supported signatures. Does libblkid find these signatures just like any other file system, during early startup? If so a generator could act on libblkid discovering something relevant, and kicking off a static dmraid-activation.service.

If this is expensive, then I wonder if it needs separate deep scan and quick scan services? Use the deep scan only on install media. And the quick scan requires a cheap hint, like a symlink or configuration file existing; or maybe an rd.XXX hint?

Comment 2 Hans de Goede 2020-02-01 23:14:49 UTC
I believe that bklid will recognize some of the firmware raid signatures which dmraid deals with, but I'm not sure if it will recognize all of them.

Although I agree that dmraid activation should probably be reworked to be triggered by udev rules rather then this being run as a service, I'm afraid that we do not have the resources to actually make this change.

I think that in the light of the resource constraints the best solution might very well be to have the dmraid activation script touch a
/var/lib/dmraid/no_dmraid_sets_found file if not sets are found and add a:


To the dmraid service file, this way we will still can for dmraid sets when starting a livecd (so anaconda does not have to manually do this and useful for using the livecd as rescue disk) and we only to the dmraid scan once on systems from the livecd, after which it will no longer start due to the condition.

One issue with this approach is that the Wants=systemd-udev-settle.service gets processes by systemd before it checks conditions, so this still drags in systemd-udev-settle.service another option might be to have the dmraid activation script disable the service when no dmraid sets are found. Now that I think about it thi might actually be the better solution.

Comment 3 Chris Murphy 2020-02-02 00:45:05 UTC
systemd-udev-settle.service is deprecated for 5+ years, there must be some other facility or mechanism that dmraid-activation.service should be using instead? And if it were doing that, would the startup delay as a result of keeping dmraid-activation.service enabled be significant?

Comment 4 Hans de Goede 2020-02-02 08:48:03 UTC
Changing the dmraid activation to not use udev-settle is quite tricky. This would require a whole bunch of things:

1) blkid to recognize all metadata formats dmraid supports
2) A whole new set of udev rules + units which call dmraid totry and assemble the set, but only if it is complete, based on events triggered by the blkid info identifying the metadata
3) Some sort of timeout mechanism to try assembling a RAID set in degraded mode in case not all members are present

As I said before I do not believe we have the resources atm to make this happen, so a small and simple modification to the shell-script which does the dmraid activation seems best. It is easy to detect in that script if there are no dmraid sets on the system and then the script can just do:

systemctl disable dmraid-activation.service

To me that seems like the best compromise here, given the available resources.

Comment 5 Ben Cotton 2020-02-11 17:20:45 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle.
Changing version to 32.

Comment 6 Morvan 2020-04-19 00:39:16 UTC
My Fedora, after a "simple Kernel update", and boot renders a PITA!
Beginning at Kernel: 5.5.13-200.fc31.x86_64 (now, Kernel: 5.5.16-200...), very slow boot; a detail: if I do not attach my RTL8821 network combo (it has two Vendor Id´s: 0bda:1a2b (Disk, Realtek Semiconductor Corp.) and 0bda:c811 (RTL8821 Network dongle); the 1a2b device ought be disabled by Driver or by a Udev rule, I chose to set one, and it worked until this Kernel series update:

$ =>cat /etc/udev/rules.d/52-remdisk.rules
# Realtek 8821CU Wifi AC USB
ATTR{idVendor}=="0bda", ATTR{idProduct}=="1a2b", RUN+="/usr/sbin/usb_modeswitch -KQ -v 0bda -p 1a2b"

I even do not need check Udev rule. It failed. I need run usb_modeswitch by hand, when this occurs; to modify lvm.conf, via filters, does not help at all.
Even I mask System-Udev-Settle Service, it renders a torment; boot incredibly slow.

Comment 7 Morvan 2020-04-19 00:45:06 UTC
(In reply to Morvan from comment #6)
> My Fedora, after a "simple Kernel update", and boot renders a PITA!...
An excerpt from $ =>systemd-analyze blame :

41.768s systemd-udev-settle.service
30.074s dracut-pre-pivot.service
 5.164s nmb.service

Comment 8 Morvan 2020-04-30 00:29:49 UTC
Here we are again. Fedora 32 (5.6.7-300.fc32), as stated, suffers from same problem:

2min 858ms systemd-udev-settle.service
   30.074s dracut-pre-pivot.service
    3.518s NetworkManager-wait-online.service
    1.616s udisks2.service
    1.464s upower.service
    1.175s dracut-initqueue.service...
Some idea? Remove dmraid from dracut? Masking services seems no help.

Comment 9 Hans de Goede 2020-04-30 09:02:27 UTC
(In reply to Morvan from comment #8)
> Some idea? Remove dmraid from dracut? Masking services seems no help.

As a workaround you can do:

dnf remove dmraid device-mapper-multipath

Note this assumes that you are not using a BIOS managed RAID set, if you are using such a RAID set, then you actually need dmraid.

Comment 10 Morvan 2020-04-30 11:22:32 UTC
(In reply to Hans de Goede from comment #9)
> (In reply to Morvan from comment #8)
> > Some idea? Remove dmraid from dracut? Masking services seems no help.
> As a workaround you can do:
> dnf remove dmraid device-mapper-multipath
> Note this assumes that you are not using a BIOS managed RAID set, if you are
> using such a RAID set, then you actually need dmraid.

Hi, Hans. Thanks for fast response. I will try. No, I really need not dmraid.

Comment 11 Morvan 2020-04-30 17:48:36 UTC
After doing Hans suggestion, I stood this:
... 30.070s dracut-pre-pivot.service
 6.270s NetworkManager-wait-online.service
 2.262s upower.service
 1.240s dracut-initqueue.service
  971ms systemd-homed.service
  811ms systemd-logind.service
  733ms systemd-machined.service ...
(it is a long time, yet; thanks Hans, but I will try to circumvent this Dracut Pre Pivot, any how).

Note You need to log in before you can comment on or make changes to this bug.