Henry Tung

Found an appropriate workaround: Add the `brcmfmac_wcc` module to `/etc/initramfs-tools/modules`, and the wireless interface will be instantiated during initramfs loading and the netplan generator won't be confused by its absence. Also found another issue where the extra `brcmfmac43456-sdio.clm_blob` firmware file isn't properly registered by the module code, so mkinitramfs skips it. That's inherited from the Raspberry Pi firmware files which introduced the extra `clm_blob`. I filed it for the Pi kernel here: https://github.com/raspberrypi/linux/issues/6828, but the same issue affects the Armbian kernel + firmware combination. The fix is either a kernel patch or an initramfs hack like the following hook: #!/bin/sh -e # Copy missing firmware files for brcmfmac driver PREREQ="" prereqs () { echo "${PREREQ}"; } case "${1}" in prereqs) prereqs; exit 0 ;; esac ; . /usr/share/initramfs-tools/hook-functions echo "Copying missing firmware files for brcmfmac..." cp /lib/firmware/brcm/brcmfmac43456-sdio.clm_blob ${DESTDIR}/lib/firmware/brcm/ The hack is unaware of any firmware file platform variants like `radxa,zero` or `radxa,rockpi4b` and such - it just turns out the `brcmfmac43456-sdio.clm_blob` file doesn't have any.

I haven't identified exactly what module load or trigger causes the network device to appear - waiting for 10 seconds during generator execution doesn't do the trick, so there is something explicit that happens post-initramfs stage that allows wlan0 to be instantiated, and if I understand the comment thread correctly, having the initramfs handle it would be the intended fix. Have to do some testing to figure out which module/firmware/etc. though, so that will have to wait for a few days until I have some time with the system to experiment.

See https://github.com/canonical/netplan/pull/456#discussion_r1569065581 The way the netplan + networkd integration is designed requires all the network devices (wlan0 in particular) to exist at /sbin/init time - otherwise, the netplan generator disables `systemd-networkd-wait-online.service` which also causes `network-online.target` to be reached early. In particular, this breaks any network FS mounts on boot. Of note, I tried logging in to file the bug via the dev contribution platform, but it looks I'm blocked from JIRA access, so am filing it here instead.