Hm I guess that nobody boots from wifi connection.

My understanding is that dracut doesn't even support it. But without this patch dracut will still try dhcp on these interfaces, which results in a major slowdown.

https://github.com/dracutdevs/dracut/commit/240c2fea10fda5c84a7725e8711d9cb214a064a9

Hi Nathaniel,
Dracut does not bring up WiFi adapter during boot by default even when e.g. ip=dhcp is used. How did you do that?

I think it was Javier who reproduced it.

Marek,

Did you try booting with the rd.neednet=1 boot param?

Yes, I tried it, but no trace, that WiFi network interface controller slows down proceeding to next Dracut phase and then to Anaconda.
I did not used Clevis at all. Just simple boot from USB stick or PXE boot with various boot parameters.

May I ask you to try to verify this bug once BETA will be released?

(In reply to Marek Hruscak from comment #12)
> Yes, I tried it, but no trace, that WiFi network interface controller slows
> down proceeding to next Dracut phase and then to Anaconda.

The filled bug says "is slow with WiFi devices" but it should actually say "is slow with wireless devices" (that's the wording I used in the Dracut fix).

Dracut only supports to bring up wired interfaces. So if there's a kernel module for a wireless device installed in the initramfs, the interface will be brough and dhclient will attempt to request an IP address for that interface. But since the wireless network isn't set up, the DHCP request will timeout.

That DHCP timeout is what causes the boot to be slower.

Dracut already has some heuristic to avoid installing drivers for WiFi devices, and that's probably why you couldn't reproduce it.

But it's heuristic is not comprehensive. For instance I was bitten by this because my machine has a Wireless WAN device whose driver module is called cdc_mbim, and that name didn't match Dracut's regular expression that's use to filter wireless modules.

So on my machine:

# WiFi device
$ grep DRIVER /sys/class/net/wlp4s0/device/uevent
DRIVER=iwlwifi
$ sudo lsinitrd /boot/initramfs-$(uname -r).img | grep iwlwifi
$

# WWAN device
$ grep DRIVER /sys/class/net/wwp0s20f0u2i12/device/uevent
DRIVER=cdc_mbim
$ sudo lsinitrd /boot/initramfs-$(uname -r).img | grep cdc_mbim
-rw-r--r--   1 root     root         5168 Nov  2 21:18 usr/lib/modules/4.14.3-300.fc27.x86_64/kernel/drivers/net/usb/cdc_mbim.ko.xz

That's why it's better to instead of rely on the module being blacklisted by Dracut, to instead have an udev rule to not bring the network interface for "wlan|wwan" devices.

You should be able to reproduce this by explicitly adding the WiFi module to your initramfs, i.e:

$ sudo dracut -f --add-drivers iwlwifi

> I did not used Clevis at all. Just simple boot from USB stick or PXE boot
> with various boot parameters.
> 

The bug is not specific to Clevis, it's just related to Clevis in the sense that its Dracut module adds the rd.neednet=1 parameter to the kernel command line which makes Dracut to attempt to get an IP address for each interface using DHCP.

> May I ask you to try to verify this bug once BETA will be released?

Sure, I can verify the bug when BETA is released, but as mentioned I believe that you can test it too by forcing to add the kernel module for your wireless device in the initramfs.

Reproduced on RHEL-7.4-20170711.0 with dracut-033-502 .
Verified on RHEL-7.5-20171130.0 with dracut-033-520 .

Thank you for explanation. Adding ath9k wireless interface controller driver to initramfs help to reproduce the bug.

Now wifi controller is omitted when waiting for network in Dracut.

Great, thanks a lot for verifying it.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0964