PREFERRED_VERSION not being populated onto the rootfs image

PREFERRED_VERSION not being populated onto the rootfs image

[John]

[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

In the latest stable version of Yocto, I've been building an image for a raspberry Pi board which has a wifi i/f on it. While trying to bring up the wifi connection I need to roll back the version of wpa_supplicant that it is using.

In the raspberrypi configure file I've put in "PREFERRED_VERSION_wpa-supplicant = "2.9". The version that is being used currently is 2.11.

I've then created a recipe file for that version and made sure that it compiles using bitbake. (Had some patching issues, all fixed).

I then run the command "bitbake core-image-minimal" and boot with the subsequent image. When I query the version of wpa-supplicant I get 2.11.

I'm unable to find any "PRIORITY" variable of any kind. Why is it grabbing the incorrect version? What have I forgotten to do?

Cheers!!

[-- Attachment #2: Type: text/html, Size: 952 bytes --]

Re: [yocto] PREFERRED_VERSION not being populated onto the rootfs image

[Alexander Kanavin]

You're not saying what the configure file is and where is it. Can you show that?

Help arrives quicker if we can reproduce the problem or at least see
your setup exactly.

Does log.do_rootfs for your image say which version of wpa supplicant
gets installed?

Alex

On Wed, 12 Feb 2025 at 20:57, John via lists.yoctoproject.org
<jdowd=slashdevslashnull.org@lists.yoctoproject.org> wrote:
>
> In the latest stable version of Yocto, I've been building an image for a raspberry Pi board which has a wifi i/f on it. While trying to bring up the wifi connection I need to roll back the version of wpa_supplicant that it is using.
>
> In the raspberrypi configure file I've put in "PREFERRED_VERSION_wpa-supplicant = "2.9". The version that is being used currently is 2.11.
>
> I've then created a recipe file for that version and made sure that it compiles using bitbake. (Had some patching issues, all fixed).
>
> I then run the command "bitbake core-image-minimal" and boot with the subsequent image. When I query the version of wpa-supplicant I get 2.11.
>
> I'm unable to find any "PRIORITY" variable of any kind. Why is it grabbing the incorrect version? What have I forgotten to do?
>
> Cheers!!
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#64787): https://lists.yoctoproject.org/g/yocto/message/64787
> Mute This Topic: https://lists.yoctoproject.org/mt/111149982/1686489
> Group Owner: yocto+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [alex.kanavin@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [yocto] PREFERRED_VERSION not being populated onto the rootfs image

[John]

[-- Attachment #1.1: Type: text/plain, Size: 1193 bytes --]

Alexander,

Thanks for your reply.

I've attached my new configure file that lives in: poky/meta-raspberrypi/conf/machine

Mea Culpa: I created this configure file and am using the MACHINE ??= "raspberrypi0-64-wf.conf" in my local.conf file.

Since the raspberrypi Zero support does not work out of the box. There is an issue in that it has to build as a 64 bit image or Raspberry Pi's boot loader won't load it. And then, the kernel modules are missing... and then the WIFI isn't installed completely and doesn't work anyways... etc... I created my own machine configuration file.

My current state has the image booting, I have a serial connection and through it I can try to bring up wifi by hand but the wpa-supplicant won't connect. My searches have found some information that it is a recent patch that has a side effect of not letting wpa-supplicant work with some raspberry Pi's. I gather an older version (2.9) does work so that's why I'm doing this.

I have no idea where the log file you referred to is or how to make bitbake generate it.

I did do a:

> 
> $ bitbake -c cleanall wpa-supplicant
> 

I can see that the correct version is referenced.

Cheers!!

[-- Attachment #1.2: Type: text/html, Size: 1637 bytes --]

[-- Attachment #2: raspberrypi0-64-wf.conf --]
[-- Type: application/octet-stream, Size: 503 bytes --]

#@TYPE: Machine
#@NAME: RaspberryPi0 2 Wifi Development Board
#@DESCRIPTION: Machine configuration for the RaspberryPi0 2 Wifi in 64 bits mode

MACHINEOVERRIDES =. "raspberrypi3-64:"

include conf/machine/raspberrypi3-64.conf

PREFERRED_VERSION_wpa-supplicant = "2.9"

MACHINE_EXTRA_RRECOMMENDS += "\
    linux-firmware-rpidistro-bcm43436 \
    linux-firmware-rpidistro-bcm43436s \
    bluez-firmware-rpidistro-bcm43430b0-hcd \
"

RPI_KERNEL_DEVICETREE = " \
    broadcom/bcm2710-rpi-zero-2.dtb \
    "

Re: [yocto] PREFERRED_VERSION not being populated onto the rootfs image

[John]

[-- Attachment #1.1: Type: text/plain, Size: 347 bytes --]

And I'm now adding the recipe file that I created (sorry, should have been in the previous message). I just copied the original recipe file. Pretty sure that isn't how it's supposed to be done but I'm going backwards in version, not forwards. Not sure how that would be handled.

And for good measure I included my local.conf file.

Cheers!!

[-- Attachment #1.2: Type: text/html, Size: 414 bytes --]

[-- Attachment #2: local.conf --]
[-- Type: application/octet-stream, Size: 13646 bytes --]

#
# This file is your local configuration file and is where all local user settings
# are placed. The comments in this file give some guide to the options a new user
# to the system might want to change but pretty much any configuration option can
# be set in this file. More adventurous users can look at
# local.conf.sample.extended which contains other examples of configuration which
# can be placed in this file but new users likely won't need any of them
# initially. There's also site.conf.sample which contains examples of site specific
# information such as proxy server addresses.
#
# Lines starting with the '#' character are commented out and in some cases the
# default values are provided as comments to show people example syntax. Enabling
# the option is a question of removing the # character and making any change to the
# variable as required.

#
# Machine Selection
#
# You need to select a specific machine to target the build with. There are a selection
# of emulated machines available which can boot and run in the QEMU emulator:
#
#MACHINE ?= "qemuarm"
#MACHINE ?= "qemuarm64"
#MACHINE ?= "qemumips"
#MACHINE ?= "qemumips64"
#MACHINE ?= "qemuppc"
#MACHINE ?= "qemux86"
#MACHINE ?= "qemux86-64"
#
# There are also the following hardware board target machines included for 
# demonstration purposes:
#
#MACHINE ?= "beaglebone-yocto"
#MACHINE ?= "genericarm64"
#MACHINE ?= "genericx86"
#MACHINE ?= "genericx86-64"
#
# This sets the default machine to be qemux86-64 if no other machine is selected:
#MACHINE ??= "raspberrypi0-wifi"
MACHINE ??= "raspberrypi0-64-wf"


# These are some of the more commonly used values. Looking at the files in the
# meta/conf/machine directory, or the conf/machine directory of any additional layers
# you add in will show all the available machines.

#
# Where to place downloads
#
# During a first build the system will download many different source code tarballs
# from various upstream projects. This can take a while, particularly if your network
# connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you
# can preserve this directory to speed up this part of subsequent builds. This directory
# is safe to share between multiple builds on the same machine too.
#
# The default is a downloads directory under TOPDIR which is the build directory.
#
#DL_DIR ?= "${TOPDIR}/downloads"

#
# Where to place shared-state files
#
# BitBake has the capability to accelerate builds based on previously built output.
# This is done using "shared state" files which can be thought of as cache objects
# and this option determines where those files are placed.
#
# You can wipe out TMPDIR leaving this directory intact and the build would regenerate
# from these files if no changes were made to the configuration. If changes were made
# to the configuration, only shared state files where the state was still valid would
# be used (done using checksums).
#
# The default is a sstate-cache directory under TOPDIR.
#
#SSTATE_DIR ?= "${TOPDIR}/sstate-cache"

#
# Where to place the build output
#
# This option specifies where the bulk of the building work should be done and
# where BitBake should place its temporary files and output. Keep in mind that
# this includes the extraction and compilation of many applications and the toolchain
# which can use Gigabytes of hard disk space.
#
# The default is a tmp directory under TOPDIR.
#
#TMPDIR = "${TOPDIR}/tmp"

#
# Default policy config
#
# The distribution setting controls which policy settings are used as defaults.
# The default value is fine for general Yocto project use, at least initially.
# Ultimately when creating custom policy, people will likely end up subclassing 
# these defaults.
#
DISTRO ?= "poky"
# As an example of a subclass there is a "bleeding" edge policy configuration
# where many versions are set to the absolute latest code from the upstream 
# source control systems. This is just mentioned here as an example, its not
# useful to most new users.
# DISTRO ?= "poky-bleeding"

#
# Package Management configuration
#
# This variable lists which packaging formats to enable. Multiple package backends
# can be enabled at once and the first item listed in the variable will be used
# to generate the root filesystems.
# Options are:
#  - 'package_deb' for debian style deb files
#  - 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager)
#  - 'package_rpm' for rpm style packages
# E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"
# OE-Core defaults to ipkg, whilst Poky defaults to rpm:
# PACKAGE_CLASSES ?= "package_rpm"

#
# SDK target architecture
#
# This variable specifies the architecture to build SDK items for and means
# you can build the SDK packages for architectures other than the machine you are
# running the build on (i.e. building i686 packages on an x86_64 host).
# Supported values are i686, x86_64, aarch64
#SDKMACHINE ?= "i686"

#
# Extra image configuration defaults
#
# The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated
# images. Some of these options are added to certain image types automatically. Some
# of the features available are:
#  "dbg-pkgs"             - add -dbg packages for all installed packages
#                           (adds symbol information for debugging/profiling)
#  "src-pkgs"             - add -src packages for all installed packages
#                           (adds source code for debugging)
#  "dev-pkgs"             - add -dev packages for all installed packages
#                           (useful if you want to develop against libs in the image)
#  "ptest-pkgs"           - add -ptest packages for all ptest-enabled packages
#                           (useful if you want to run the package test suites)
#  "tools-sdk"            - add development tools (gcc, make, pkgconfig etc.)
#  "tools-debug"          - add debugging tools (gdb, strace)
#  "eclipse-debug"        - add Eclipse remote debugging support
#  "tools-profile"        - add profiling tools (oprofile, lttng, valgrind)
#  "tools-testapps"       - add useful testing tools (ts_print, aplay, arecord etc.)
#  "allow-empty-password" - allow users to have an empty password
#  "empty-root-password"  - the root user has no password set
#  "allow-root-login      - the root user can login
# There are other features that can be used here too, see
# meta/classes-recipe/image.bbclass and
# meta/classes-recipe/core-image.bbclass for more details.
# We default to allowing root login without a password for convenience.
EXTRA_IMAGE_FEATURES ?= "allow-empty-password empty-root-password allow-root-login"

#
# Additional image features
#
# The following is a list of additional classes to use when building images which
# enable extra features. Some available options which can be included in this variable
# are:
#   - 'buildstats' collect build statistics
USER_CLASSES ?= "buildstats"

#
# Runtime testing of images
#
# The build system can test booting virtual machine images under qemu (an emulator)
# after any root filesystems are created and run tests against those images. It can also
# run tests against any SDK that are built. To enable this uncomment these lines.
# See meta/classes-recipe/test{image,sdk}.bbclass for further details.
#IMAGE_CLASSES += "testimage testsdk"
#TESTIMAGE_AUTO:qemuall = "1"

#
# Interactive shell configuration
#
# Under certain circumstances the system may need input from you and to do this it
# can launch an interactive shell. It needs to do this since the build is
# multithreaded and needs to be able to handle the case where more than one parallel
# process may require the user's attention. The default is iterate over the available
# terminal types to find one that works.
#
# Examples of the occasions this may happen are when resolving patches which cannot
# be applied, to use the devshell or the kernel menuconfig
#
# Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x only), none
# Note: currently, Konsole support only works for KDE 3.x due to the way
# newer Konsole versions behave
#OE_TERMINAL = "auto"
# By default disable interactive patch resolution (tasks will just fail instead):
PATCHRESOLVE = "noop"

#
# Disk Space Monitoring during the build
#
# Monitor the disk space during the build. If there is less that 1GB of space or less
# than 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR), gracefully
# shutdown the build. If there is less than 100MB or 1K inodes, perform a hard halt
# of the build. The reason for this is that running completely out of space can corrupt
# files and damages the build in ways which may not be easily recoverable.
# It's necessary to monitor /tmp, if there is no space left the build will fail
# with very exotic errors.
BB_DISKMON_DIRS ??= "\
    STOPTASKS,${TMPDIR},1G,100K \
    STOPTASKS,${DL_DIR},1G,100K \
    STOPTASKS,${SSTATE_DIR},1G,100K \
    STOPTASKS,/tmp,100M,100K \
    HALT,${TMPDIR},100M,1K \
    HALT,${DL_DIR},100M,1K \
    HALT,${SSTATE_DIR},100M,1K \
    HALT,/tmp,10M,1K"

#
# Shared-state files from other locations
#
# As mentioned above, shared state files are prebuilt cache data objects which can be
# used to accelerate build time. This variable can be used to configure the system
# to search other mirror locations for these objects before it builds the data itself.
#
# This can be a filesystem directory, or a remote url such as https or ftp. These
# would contain the sstate-cache results from previous builds (possibly from other
# machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the
# cache locations to check for the shared objects.
# NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH
# at the end as shown in the examples below. This will be substituted with the
# correct path within the directory structure.
#SSTATE_MIRRORS ?= "\
#file://.* https://someserver.tld/share/sstate/PATH;downloadfilename=PATH \
#file://.* file:///some/local/dir/sstate/PATH"

#
# Yocto Project SState Mirror
#
# The Yocto Project has prebuilt artefacts available for its releases, you can enable
# use of these by uncommenting some of the following lines. This will mean the build uses
# the network to check for artefacts at the start of builds, which does slow it down
# initially but it will then speed up the builds by not having to build things if they are
# present in the cache. It assumes you can download something faster than you can build it
# which will depend on your network.
# Note: For this to work you also need hash-equivalence passthrough to the matching server
# There is a choice between our sstate server directly and a faster content delivery network
# (CDN) kindly provided by JSDelivr, uncomment one of the SSTATE_MIRRORS lines, not both.
# Using the CDN rather than the yoctoproject.org address is suggested/preferred.
#
#BB_HASHSERVE_UPSTREAM = 'wss://hashserv.yoctoproject.org/ws'
#SSTATE_MIRRORS ?= "file://.* http://cdn.jsdelivr.net/yocto/sstate/all/PATH;downloadfilename=PATH"
#
###SSTATE_MIRRORS ?= "file://.* http://sstate.yoctoproject.org/all/PATH;downloadfilename=PATH"


#
# Qemu configuration
#
# By default native qemu will build with a builtin VNC server where graphical output can be
# seen. The line below enables the SDL UI frontend too.
PACKAGECONFIG:append:pn-qemu-system-native = " sdl"
# By default libsdl2-native will be built, if you want to use your host's libSDL instead of 
# the minimal libsdl built by libsdl2-native then uncomment the ASSUME_PROVIDED line below.
ASSUME_PROVIDED += "libsdl2-native"

# You can also enable the Gtk UI frontend, which takes somewhat longer to build, but adds
# a handy set of menus for controlling the emulator.
#PACKAGECONFIG:append:pn-qemu-system-native = " gtk+"

#
# Hash Equivalence
#
# Enable support for automatically running a local hash equivalence server and
# instruct bitbake to use a hash equivalence aware signature generator. Hash
# equivalence improves reuse of sstate by detecting when a given sstate
# artifact can be reused as equivalent, even if the current task hash doesn't
# match the one that generated the artifact.
#
# A shared hash equivalent server can be set with "<HOSTNAME>:<PORT>" format
#
#BB_HASHSERVE = "auto"
#BB_SIGNATURE_HANDLER = "OEEquivHash"

#
# Memory Resident Bitbake
#
# Bitbake's server component can stay in memory after the UI for the current command
# has completed. This means subsequent commands can run faster since there is no need
# for bitbake to reload cache files and so on. Number is in seconds, after which the
# server will shut down.
#
#BB_SERVER_TIMEOUT = "60"

# CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
# track the version of this file when it was generated. This can safely be ignored if
# this doesn't mean anything to you.
CONF_VERSION = "2"
INHERIT += "rm_work"

DL_DIR ?= "/home/users/yocto_shared/downloads"
SSTATE_DIR ?= "/home/users/yocto_shared/sstate-cache"

# for CPU count and how many parallel threads will be used
BB_NUMBER_THREADS = "6"
MACHINE_FEATURES = " bluetooth wifi usbhost"

PREFERRED_PROVIDER_virtual/kernel = "linux-raspberrypi"
#IMAGE_INSTALL:append = " linux-firmware-bcm43430 wpa-supplicant dhcpcd"
IMAGE_INSTALL:append = " linux-firmware-bcm43430 bluez5 i2c-tools wpa-supplicant"
ENABLE_UART = "1"
SERIAL_CONSOLE = "tty1"
DISABLE_RPI_BOOT_LOGO = "1"
DISABLE_OVERSCAN = "1"
DISABLE_SPLASH = "1"
BOOT_DELAY = "0"
GPU_MEM = "16"
PACKAGE_CLASSES = "package_ipk"
DISTRO_FEATURES:append = " wifi "
IMAGE_FSTYPES = "tar.bz2 ext4 rpi-sdimg"
SDIMG_ROOTFS_TYPE = "ext4"


[-- Attachment #3: wpa-supplicant_2.9.bb --]
[-- Type: application/octet-stream, Size: 5514 bytes --]

SUMMARY = "Client for Wi-Fi Protected Access (WPA)"
DESCRIPTION = "wpa_supplicant is a WPA Supplicant for Linux, BSD, Mac OS X, and Windows with support for WPA and WPA2 (IEEE 802.11i / RSN). Supplicant is the IEEE 802.1X/WPA component that is used in the client stations. It implements key negotiation with a WPA Authenticator and it controls the roaming and IEEE 802.11 authentication/association of the wlan driver."
HOMEPAGE = "http://w1.fi/wpa_supplicant/"
BUGTRACKER = "http://w1.fi/security/"
SECTION = "network"
LICENSE = "BSD-3-Clause"
LIC_FILES_CHKSUM = "file://COPYING;md5=279b4f5abb9c153c285221855ddb78cc \
                    file://README;beginline=1;endline=56;md5=e7d3dbb01f75f0b9799e192731d1e1ff \
                    file://wpa_supplicant/wpa_supplicant.c;beginline=1;endline=12;md5=0a8b56d3543498b742b9c0e94cc2d18b"

DEPENDS = "dbus libnl"

# file://0001-macsec_linux-Hardware-offload-requires-Linux-headers.patch

SRC_URI = "http://w1.fi/releases/wpa_supplicant-${PV}.tar.gz \
           file://wpa-supplicant.sh \
           file://wpa_supplicant.conf \
           file://wpa_supplicant.conf-sane \
           file://99_wpa_supplicant \
           "

SRC_URI[sha256sum] = "fcbdee7b4a64bea8177973299c8c824419c413ec2e3a95db63dd6a5dc3541f17"

S = "${WORKDIR}/wpa_supplicant-${PV}"

inherit pkgconfig systemd

PACKAGECONFIG ?= "openssl"
PACKAGECONFIG[gnutls] = ",,gnutls libgcrypt"
PACKAGECONFIG[openssl] = ",,openssl"

CVE_PRODUCT = "wpa_supplicant"

CVE_STATUS[CVE-2024-5290] = "not-applicable-platform: this only affects Ubuntu and other platforms patching wpa-supplicant"

EXTRA_OEMAKE = "'LIBDIR=${libdir}' 'INCDIR=${includedir}' 'BINDIR=${sbindir}'"

do_configure () {
	${MAKE} -C wpa_supplicant clean
	sed -e '/^CONFIG_TLS=/d' <wpa_supplicant/defconfig >wpa_supplicant/.config

	if ${@ bb.utils.contains('PACKAGECONFIG', 'openssl', 'true', 'false', d) }; then
		echo 'CONFIG_TLS=openssl' >>wpa_supplicant/.config
	elif ${@ bb.utils.contains('PACKAGECONFIG', 'gnutls', 'true', 'false', d) }; then
		echo 'CONFIG_TLS=gnutls' >>wpa_supplicant/.config
        sed -i -e 's/\(^CONFIG_DPP=\)/#\1/' \
               -e 's/\(^CONFIG_EAP_PWD=\)/#\1/' \
               -e 's/\(^CONFIG_SAE=\)/#\1/' wpa_supplicant/.config
	fi

	# For rebuild
	rm -f wpa_supplicant/*.d wpa_supplicant/dbus/*.d
}

do_compile () {
	oe_runmake -C wpa_supplicant
	if [ -z "${DISABLE_STATIC}" ]; then
		oe_runmake -C wpa_supplicant libwpa_client.a
	fi
}

do_install () {
	oe_runmake -C wpa_supplicant DESTDIR="${D}" install

	install -d ${D}${docdir}/wpa_supplicant
	install -m 644 wpa_supplicant/README ${UNPACKDIR}/wpa_supplicant.conf ${D}${docdir}/wpa_supplicant

	install -d ${D}${sysconfdir}
	install -m 600 ${UNPACKDIR}/wpa_supplicant.conf-sane ${D}${sysconfdir}/wpa_supplicant.conf

	install -d ${D}${sysconfdir}/network/if-pre-up.d/
	install -d ${D}${sysconfdir}/network/if-post-down.d/
	install -d ${D}${sysconfdir}/network/if-down.d/
	install -m 755 ${UNPACKDIR}/wpa-supplicant.sh ${D}${sysconfdir}/network/if-pre-up.d/wpa-supplicant
	ln -sf ../if-pre-up.d/wpa-supplicant ${D}${sysconfdir}/network/if-post-down.d/wpa-supplicant

	install -d ${D}/${sysconfdir}/dbus-1/system.d
	install -m 644 ${S}/wpa_supplicant/dbus/dbus-wpa_supplicant.conf ${D}/${sysconfdir}/dbus-1/system.d
	install -d ${D}/${datadir}/dbus-1/system-services
	install -m 644 ${S}/wpa_supplicant/dbus/*.service ${D}/${datadir}/dbus-1/system-services

	if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
		install -d ${D}/${systemd_system_unitdir}
		install -m 644 ${S}/wpa_supplicant/systemd/*.service ${D}/${systemd_system_unitdir}
	fi

	install -d ${D}/etc/default/volatiles
	install -m 0644 ${UNPACKDIR}/99_wpa_supplicant ${D}/etc/default/volatiles

	install -d ${D}${includedir}
	install -m 0644 ${S}/src/common/wpa_ctrl.h ${D}${includedir}

	if [ -z "${DISABLE_STATIC}" ]; then
		install -d ${D}${libdir}
		install -m 0644 wpa_supplicant/libwpa_client.a ${D}${libdir}
	fi
}

pkg_postinst:${PN} () {
	# If we're offline, we don't need to do this.
	if [ "x$D" = "x" ]; then
		killall -q -HUP dbus-daemon || true
	fi
}

PACKAGE_BEFORE_PN += "${PN}-passphrase ${PN}-cli"
PACKAGES =+ "${PN}-lib"
PACKAGES += "${PN}-plugins"
ALLOW_EMPTY:${PN}-plugins = "1"

PACKAGES_DYNAMIC += "^${PN}-plugin-.*$"
NOAUTOPACKAGEDEBUG = "1"

FILES:${PN}-passphrase = "${sbindir}/wpa_passphrase"
FILES:${PN}-cli = "${sbindir}/wpa_cli"
FILES:${PN}-lib = "${libdir}/libwpa_client*${SOLIBSDEV}"
FILES:${PN} += "${datadir}/dbus-1/system-services/* ${systemd_system_unitdir}/*"
FILES:${PN}-dbg += "${sbindir}/.debug ${libdir}/.debug"

CONFFILES:${PN} += "${sysconfdir}/wpa_supplicant.conf"

RRECOMMENDS:${PN} = "${PN}-passphrase ${PN}-cli ${PN}-plugins"

SYSTEMD_SERVICE:${PN} = "wpa_supplicant.service"
SYSTEMD_AUTO_ENABLE = "disable"

python split_wpa_supplicant_libs () {
    libdir = d.expand('${libdir}/wpa_supplicant')
    dbglibdir = os.path.join(libdir, '.debug')

    split_packages = do_split_packages(d, libdir, r'^(.*)\.so', '${PN}-plugin-%s', 'wpa_supplicant %s plugin', prepend=True)
    split_dbg_packages = do_split_packages(d, dbglibdir, r'^(.*)\.so', '${PN}-plugin-%s-dbg', 'wpa_supplicant %s plugin - Debugging files', prepend=True, extra_depends='${PN}-dbg')

    if split_packages:
        pn = d.getVar('PN')
        d.setVar('RRECOMMENDS:' + pn + '-plugins', ' '.join(split_packages))
        d.appendVar('RRECOMMENDS:' + pn + '-dbg', ' ' + ' '.join(split_dbg_packages))
}
PACKAGESPLITFUNCS += "split_wpa_supplicant_libs"

Re: [yocto] PREFERRED_VERSION not being populated onto the rootfs image

[Alexander Kanavin]

Sure, but do you still have a problem? I'm not certain after reading
your messages.

Alex

On Thu, 13 Feb 2025 at 16:09, John via lists.yoctoproject.org
<jdowd=slashdevslashnull.org@lists.yoctoproject.org> wrote:
>
> And I'm now adding the recipe file that I created (sorry, should have been in the previous message). I just copied the original recipe file. Pretty sure that isn't how it's supposed to be done but I'm going backwards in version, not forwards. Not sure how that would be handled.
>
> And for good measure I included my local.conf file.
>
> Cheers!!
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#64801): https://lists.yoctoproject.org/g/yocto/message/64801
> Mute This Topic: https://lists.yoctoproject.org/mt/111149982/1686489
> Group Owner: yocto+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [alex.kanavin@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [yocto] PREFERRED_VERSION not being populated onto the rootfs image

[John]

[-- Attachment #1: Type: text/plain, Size: 17 bytes --]

Yes

Cheers!!

[-- Attachment #2: Type: text/html, Size: 56 bytes --]

Re: [yocto] PREFERRED_VERSION not being populated onto the rootfs image

[John]

[-- Attachment #1: Type: text/plain, Size: 808 bytes --]

So, I added "dhcpcd" to this line in my local.conf file:

> 
> IMAGE_INSTALL:append = " linux-firmware-bcm43430 bluez5 i2c-tools
> wpa-supplicant dhcpcd"
> 

and voila, I have my wpa_supplicant v2.9 installed.... so any ideas why this worked?

And with that, I ran the wpa_supplicant and I now have wifi working on a raspberry Pi Zero 2 W running a Yocto 64-bit image.

The negative is that wpa-supplicant 2.9 doesn't take a passphrase that's encoded so I have a clear text PSK in the file. That will need to be fixed. I guess the patch that causes the issues with 2.11 needs to be identified and removed. I'm sure that will be tedious.

Any tests or information about my build that is requested will certainly be done if you think it will be constructive and helpful to the cause.

Cheers!!

[-- Attachment #2: Type: text/html, Size: 965 bytes --]

Re: [yocto] PREFERRED_VERSION not being populated onto the rootfs image

[John]

[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]

And now I have a working raspberrypi Zero 2 W with wifi (comes up automatically) and probably a working Bluetooth (not of importance to me right now but there appears to be an interface for it).

With the addition of the dhcpcd s/w shown above I had a working wpa-supplicant as it replaced the 2.11 version with the 2.9 version. My next problem was to get the wifi to start automatically. This was done by creating my own "interfaces" file under "init-updown" in the recipes-connectivity right here:

> 
> ./recipes-core/init-ifupdown/init-ifupdown-1.0/raspberrypi0-64-wf/interfaces
> 
> 

This file will be installed to /etc/network.

Somewhere I ran across this setup in which you can just override a generic file by placing the same file in a sub-directory prefixed with the machine name you are using. This will prioritise this version of the file. In that file I removed some of the references to "eth0" and "eth1" and made sure "wlan0" was set to auto.

So I consider my issue all closed and then some.

Cheers!!

[-- Attachment #2: Type: text/html, Size: 1229 bytes --]

Re: [yocto] PREFERRED_VERSION not being populated onto the rootfs image

[John]

[-- Attachment #1: Type: text/plain, Size: 118 bytes --]

Last bit of cleanup, of course the ".conf" file takes the encoded passphrase. I had a fat-finger moment.

Cheers!!

[-- Attachment #2: Type: text/html, Size: 157 bytes --]