[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#999485: [Pkg-raspi-maintainers] Bug#948712: raspi-firmware: Workaround to avoid postinst error on Pinebook Pro



Thanks for your feedback, Cyril!

On 12/13/25 13:06, Cyril Brulebois wrote:
Paul Seelig <wmlive@users.sf.net> (2025-12-12):
The proposed modification consists of an additional check to verify if
the platfom actually is an RPI before raising an error condition just
because /boot/firmware is not a mount point.
We support much more than just the Pi 4 family. You seem to have
borrowed from a function that matches the Pi 4 family specifically
because of cma-related requirements (having it or not having it on the
kernel cmdline).
Just reusing the very same function that was already defined by the package maintainer in debian/kernel/postinst.d/z50-raspi-firmware and trying to avoid that pointless (for a PINE64 device) error condition.

On Pinebook Pro and some other PINE64 devices, /boot/firmware is
usually just a subdirectory and there is no need to complicate things
by insisting it to be a mount point.
Why are you deploying *raspi*-firmware on PINE devices in the first
place?
A cursory read of the full thread https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948712 should easily make this clearer.

The very same issue applies for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064072, where a Pine64 RockPro64 is affected. A closely related bug was filed via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999485 for the firmware-brcm80211 package.

The raspi-firmware package contains the /lib/firmware/brcm/brcmfmac434* blobs that are required to use the Wifi capabilities of some PINE64 devices, including the Pinebook Pro. These files would probably be better positioned as part of the firmware-brcm80211 or other firmware package, but there appear to be some reasons that impedes this so far.

Those using a Pinebook Pro are basically "condemned" to use the raspi-firmware package for this blob component if we won't proper network connectivity in Debian. And since the raspi-fimrware package is designed with mostly RPI's in mind, these unfortunate postinst error conditions arise if used outside of the intended scope.

Discerning RPI's in the postinst scripts from other ARM devices that use the included firmware in different ways would very much help its wider user base.

Thanks!
Paul


Reply to: