Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#64393 - community/mkinitcpio-netconf: breaks iwlwifi module

Attached to Project: Arch Linux
Opened by Alexander E. Patrakov (patrakov) - Tuesday, 05 November 2019, 04:01 GMT
Last edited by Giancarlo Razzolini (grazzolini) - Tuesday, 05 November 2019, 18:39 GMT
Task Type Bug Report
Category Packages: Extra
Status Assigned
Assigned To Giancarlo Razzolini (grazzolini)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

Description: if I include netconf in HOOKS in /etc/mkinitcpio.conf, then WiFi adapter is no longer found in the main system.


Additional info:
* package version(s): community/mkinitcpio-netconf 0.0.5-1
* config and/or log files etc.: see below

Steps to reproduce:

1. Configure the PC with an Intel WiFi card to connect to a wired LAN and act as a WiFi access point (OK, if you are lazy, skip the access point, it is sufficient to test that wlp4s0 exists).
2. Add netconf in HOOKS in /etc/mkinitcpio.conf (was an attempt to add remote LUKS unlock via community/mkinitcpio-dropbear).
3. Observe that the main system no longer has wlp4s0 interface.

# lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation 4th Gen Core Processor DRAM Controller [8086:0c00] (rev 06)
00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06)
00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [8086:0c0c] (rev 06)
00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 04)
00:16.0 Communication controller [0780]: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 [8086:8c3a] (rev 04)
00:1a.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 [8086:8c2d] (rev 04)
00:1b.0 Audio device [0403]: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller [8086:8c20] (rev 04)
00:1c.0 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 [8086:8c10] (rev d4)
00:1c.2 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #3 [8086:8c14] (rev d4)
00:1c.3 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #4 [8086:8c16] (rev d4)
00:1c.4 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #5 [8086:8c18] (rev d4)
00:1d.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 [8086:8c26] (rev 04)
00:1f.0 ISA bridge [0601]: Intel Corporation Z87 Express LPC Controller [8086:8c44] (rev 04)
00:1f.2 SATA controller [0106]: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] [8086:8c02] (rev 04)
00:1f.3 SMBus [0c05]: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller [8086:8c22] (rev 04)
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 0c)
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 0c)
04:00.0 Network controller [0280]: Intel Corporation Centrino Advanced-N 6235 [8086:088e] (rev 24)

The WiFi controller is normally handled by the iwlwifi module, and the netconf hook includes it in the initramfs, for no good reason. The problem is that iwlwifi does not work by itself, it relies on support from helper modules, iwldvm (for my hardware) and iwlmvm (for others) or possibly some other iwl stuff. These helper modules are not included in the initramfs, and therefore are not loaded when the PC boots, thus the WiFi adapter no longer works.

Logs:

[ 2.353387] iwlwifi 0000:04:00.0: enabling device (0000 -> 0002)
[ 2.353513] iwlwifi 0000:04:00.0: can't disable ASPM; OS doesn't have ASPM control
[ 2.353975] iwlwifi 0000:04:00.0: loaded firmware version 18.168.6.1 op_mode iwldvm

If I load iwldvm manually, the following lines appear, and the adapter works, but I should not have to do it manually:

[ 5960.550178] iwlwifi 0000:04:00.0: CONFIG_IWLWIFI_DEBUG enabled
[ 5960.550180] iwlwifi 0000:04:00.0: CONFIG_IWLWIFI_DEBUGFS enabled
[ 5960.550181] iwlwifi 0000:04:00.0: CONFIG_IWLWIFI_DEVICE_TRACING enabled
[ 5960.550182] iwlwifi 0000:04:00.0: Detected Intel(R) Centrino(R) Advanced-N 6235 AGN, REV=0xB0
[ 5960.583410] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
[ 5960.588337] iwlwifi 0000:04:00.0 wlp4s0: renamed from wlan0
[ 5960.620909] iwlwifi 0000:04:00.0: Radio type=0x2-0x1-0x0
[ 5960.927057] iwlwifi 0000:04:00.0: Radio type=0x2-0x1-0x0
[ 5961.035779] iwlwifi 0000:04:00.0: Radio type=0x2-0x1-0x0
[ 5961.334847] iwlwifi 0000:04:00.0: Radio type=0x2-0x1-0x0
This task depends upon

Comment by Alexander E. Patrakov (patrakov) - Tuesday, 05 November 2019, 04:08 GMT
Just as a data point, I don't have systemd in the initramfs, so the misbehaving line in the hook is this one:

add_checked_modules "/drivers/net/"
Comment by Giancarlo Razzolini (grazzolini) - Tuesday, 05 November 2019, 13:51 GMT
Are you using iwd by any chance? Just adding a hook on mkinitcpio.conf and rebuilding the initramfs doesn't alter anything on the running system. If you're using iwd, it is expected behavior for it to remove the interface, because it's how it operates.
Comment by Alexander E. Patrakov (patrakov) - Tuesday, 05 November 2019, 13:54 GMT
No, I am not using iwd. And you have apparently misunderstood the bug description, so let me clarify.

If I don't enable the netconf hook, then WiFi works. If I rebuild the initramfs with the netconf hook, then on the next reboot WiFi becomes broken, because now the initramfs (and not the main system) loads iwlwifi, and at that time the iwldvm module is not available, and is never retried.
Comment by Giancarlo Razzolini (grazzolini) - Tuesday, 05 November 2019, 15:07 GMT
I understood the bug description, just wanted to make sure you were not using something else that would cause this behavior. I'll try to reproduce this later today, I also have iwlwifi with iwldvm.
Comment by Giancarlo Razzolini (grazzolini) - Tuesday, 05 November 2019, 17:42 GMT
It looks like this doesn't have anything to netconf. I am able to reproduce this behavior without netconf. It seems that systemd persistent naming feature is borked. I get a wlan0 card when booting without netconf.
Comment by Alexander E. Patrakov (patrakov) - Tuesday, 05 November 2019, 17:48 GMT
This would be a different bug.
Comment by Alexander E. Patrakov (patrakov) - Tuesday, 05 November 2019, 17:49 GMT
Just to reiterate.

no netconf: I get wlp4s0

netconf + autodetect: I get nothing

netconf + autodetect + manual modprobe of iwldvm: I get wlp4s0
Comment by Alexander E. Patrakov (patrakov) - Tuesday, 05 November 2019, 17:53 GMT
The proper solution would be to include iwldvm + iwlmvm every time autodetection says that iwlwifi needs to be included. These modules are inseparable. Similar case to vfat + nls_cp437 + nls_iso8859-1 which is already handled by add_module() in /usr/lib/initcpio/functions.
Comment by Giancarlo Razzolini (grazzolini) - Tuesday, 05 November 2019, 17:58 GMT
I have opened an upstream issue to track this: https://github.com/systemd/systemd/issues/13948

It would be helpful to try to reproduce this with other wireless cards. Here on my system I'm also using iwlwifi with iwldvm, and I can replicate this issue.
Comment by Alexander E. Patrakov (patrakov) - Tuesday, 05 November 2019, 17:59 GMT
You reported a completely different issue. I never see wlan0.
Comment by Alexander E. Patrakov (patrakov) - Tuesday, 05 November 2019, 18:01 GMT
Could you please paste the output of this command, just to see what's different in our setup:

lsinitcpio /boot/initramfs-linux.img | grep iwl
Comment by Giancarlo Razzolini (grazzolini) - Tuesday, 05 November 2019, 18:05 GMT
Are you sure you never see wlan0? because this line indicates otherwise:

[ 5960.588337] iwlwifi 0000:04:00.0 wlp4s0: renamed from wlan0

The autodetect hook doesn't even care about network modules. netconf uses add_checked_modules because it's the proper way to filter the modules that were detected by autodetect already.
Comment by Alexander E. Patrakov (patrakov) - Tuesday, 05 November 2019, 18:08 GMT
Yes, I am sure. [ 5960.588337] is when I ran "modprobe iwldvm" manually. So it immediately created the interface, wlan0, and then udev renamed it to wlp4s0 according to the usual rules.

> netconf uses add_checked_modules because it's the proper way to filter the modules that were detected by autodetect already.

This "proper way" is buggy, because it separates iwlwifi from its required helpers, iwldvm and iwlmvm. I guess we just need to fix add_module() in /usr/lib/initcpio/functions, i.e. add one more special case, just like the vfat case which is already there.
Comment by Giancarlo Razzolini (grazzolini) - Tuesday, 05 November 2019, 18:33 GMT
@Alexander,

I have done a few more tests here. To make sure iwd and any other network managing software had anything to do with it, I have disabled them all on boot.

So, to summarize:

When using netconf:

I don't get neither a wlp2s0 nor wlan0 device. My system boots only with the iwlwifi module loaded.
If I manually load the iwlmvm/iwldvm modules, I *still* get a wlan0 device. It doesn't get renamed as in your case.

When not using netconf:

I get a wlan0 device.

So, it seems to be two separate issues.
Comment by Giancarlo Razzolini (grazzolini) - Tuesday, 05 November 2019, 18:43 GMT
The naming issue is related to iwd shipping a link file. I have renamed this task and re-assigned. I'll see if adding the iwl modules is *really* necessary, or if there's a better way to do this on netconf.

Edited to add: my suggestion to you, for now, is to add the modules to the MODULES=() array in mkinitcpio.conf.
Comment by Alexander E. Patrakov (patrakov) - Tuesday, 05 November 2019, 18:52 GMT
I did exactly that, but still thanks ;)
Comment by Giancarlo Razzolini (grazzolini) - Tuesday, 05 November 2019, 19:07 GMT
Sure. If a mkinitcpio fix is required, that might take a few weeks to land. If this can be done on mkinitcpio-netconf side, it's a little easier. So, I suggest for now you add them. I'll keep this opened in the mean time, so keep an eye for it.
Comment by Alexander E. Patrakov (patrakov) - Sunday, 06 September 2020, 18:11 GMT
(writing as requested by the draft of the "bug wrangling day" news item)

Nothing has changed. The iwlwifi module's operation still depends on the iwlmvm or iwldvm (depending on the hardware), but it loads these helpers dynamically at runtime. See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/intel/iwlwifi/iwl-drv.c?h=v5.8#n1603

There is no "softdep" in "modinfo iwlwifi" for the mkinitcpio scripts to catch upon and detect this de-facto dependency, so the workaround still stays here.

I have grepped the whole drivers/net tree for request_module, and found the following cases that might be exposing the same issue:

mlx4_core might request mlx4_en or mlx4_ib
mlx5_core might request mlx5_ib
iwlwifi could request iwlvdm or iwlmvm, as already reported
hostap, ipw2100 and ipw2200 might request lib80211_crypt_wep or lib80211_crypt_tkip or lib80211_crypt_ccmp (but not sure if this could happen during early boot)

Please (as already suggested) handle these cases just like you do the fat -> nls_cp437 hidden dependency, or document (by closing this bug) that autodetection isn't supposed to work on hardware with drivers that load helper modules at runtime, and the user really has to put the required helper modules into MODULES=(...).

Loading...