Package Details: system76-firmware 1.0.41-1

Git Clone URL: (read-only, click to copy)
Package Base: system76-firmware
Description: System76 CLI tool for installing firmware updates
Upstream URL:
Licenses: GPL3
Submitter: yochananmarqos
Maintainer: yochananmarqos
Last Packager: yochananmarqos
Votes: 9
Popularity: 0.000023
First Submitted: 2021-02-05 19:26 (UTC)
Last Updated: 2022-06-22 16:16 (UTC)

Pinned Comments

yochananmarqos commented on 2021-02-16 08:30 (UTC)

PSA: The CLI and daemon are now split into separate packages to match upstream. You'll have to uninstall system76-firmware-daemon <=1.0.23-1 to upgrade to >=1.0.23-2.

Latest Comments

yochananmarqos commented on 2021-02-16 08:30 (UTC)

PSA: The CLI and daemon are now split into separate packages to match upstream. You'll have to uninstall system76-firmware-daemon <=1.0.23-1 to upgrade to >=1.0.23-2.

yochananmarqos commented on 2021-02-05 21:58 (UTC)

@spastorino: Again, that's the point of building in a chroot. You can keep your rustup and build in a chroot using rust.

spastorino commented on 2021-02-05 21:17 (UTC)

@yochananmarqos ahhh I see, it depends on rust but:

rust (rust-i586-git, rust-git, rust-mrustc, rust-bin, rustup-git, rust-nightly, rust-nightly-bin, rust-wasm, rustup)

On my machine:

$ pacman -Q | grep rust rustup 1.23.1-1 $

And as listed, rustup provides rust. So when I run makepkg, it downloads whatever version rustup-toolchain file says and that's why it doesn't work on my machine. So whoever has the same setup I have which is to have rustup to manage all the rust installations, would have the same issue. Anyway, I saw Jeremy released and you updated the package so everyone happy :).

yochananmarqos commented on 2021-02-04 23:58 (UTC)

@spastorino: Yes, I did read it. However, it seems to be irrelevant to this package since it depends on rust which is currently at 1.49.0.

spastorino commented on 2021-02-04 23:42 (UTC)

@yochananmarqos yeah I understand that, did you read my comments on the github commit I've shared?. What I don't understand is how this 1.0.22 version even works. 1.0.22 is using a version of the object crate that uses slice patterns, which was introduced in Rust 1.42 and the repo states in rust-toolchain that the Rust version used is 1.41. All I can think is that rust-toolchain on certain setups is ignored or something like that.

yochananmarqos commented on 2021-02-04 21:36 (UTC)

@spastorino: Building in a clean chroot helps ensure a reproducible build without interference from environment / user variables.

spastorino commented on 2021-02-04 21:00 (UTC)

@yochananmarqos to be honest I did not investigate too deeply but I've seen people saying that it compiles for them and I can't understand how, unless you're not using rust-toolchain provided Rust version. rust-toolchain on the system76-firmware repo states that the Rust version used is 1.41, so the script on my machines downloads Rust 1.41 and that version fails because 1.41 doesn't support slice patterns. I guess you may be using system rust or something? and that version is newer than 1.41?.

yochananmarqos commented on 2021-02-04 16:33 (UTC)

@spastorino: It builds fine for me with rust in a clean chroot.

spastorino commented on 2021-02-04 14:28 (UTC)

The new 1.0.22 version does not compile. I've explained why here

Just pushed a PR mainstream to fix this, Jeremy told me that they are going to merge my PR and make a new release soon.

yochananmarqos commented on 2020-12-13 00:08 (UTC)

@dreieck. Please see my comment here.

dreieck commented on 2020-12-12 23:34 (UTC)

Your PKGBUILD downloads stuff in build().

This must not happen. No internet connection must be assumed in build() and package().

Please make sure that everything needed to build the software is downloaded in the source-array, if that is not possible use the prepare()-function and download stuff there. (source-array has the advantage that user's makepkg.conf-settings are honoured.)

==> Starting build()...
 Downloading    Blocking waiting for file lock on package cache
  Downloaded form_urlencoded v1.0.0
  Downloaded rustc-demangle v0.1.18
  Downloaded cc v1.0.62
  Downloaded sha2 v0.9.2
  Downloaded hashbrown v0.9.1
  Downloaded serde v1.0.117
[ downloading lots of stuff ]
 Downloading 2 crates, remaining bytes: 901.4 KB                                                                                                                                                                                           

Thanks for maintaining!

AHoneybun commented on 2020-11-03 19:49 (UTC)

I would recommend updating the PKGBUILD file like this:

Maintainer: Corey Hinshaw <corey(at)electrickite(dot)org>

pkgname=system76-firmware-daemon _pkgname=system76-firmware pkgver=1.0.19 pkgrel=1 pkgdesc='System76 Firmware Daemon provides a daemon for installing firmware updates.' arch=('x86_64') url='' license=('GPL3') install="${pkgname}.install" depends=( 'ca-certificates' 'dbus' 'dfu-programmer' 'efibootmgr' 'openssl' 'systemd' 'xz' ) makedepends=('rust') conflicts=('system76-driver<=17.10.32') source=("${_pkgname}/archive/${pkgver}.tar.gz" "${pkgname}.install") sha256sums=('123fbe5ea5cfb114be8c099845e8a2746a6eeb0ab813cc93df19353db4a24087' 'bee86280bc6762aa773ef17441126df336abb3f4ca2163caa4df6201b6a2d708')

build() { cd ${srcdir}/${_pkgname}-${pkgver} make prefix=/usr DESTDIR="${pkgdir}" }

package() { cd ${srcdir}/${_pkgname}-${pkgver} make prefix=/usr DESTDIR="${pkgdir}" install }

This updates the package to 1.0.19 from 1.0.17-1 and adds efibootmgr as a depends since it is needed to apply the firmware update on the next boot.

electrickite commented on 2020-08-18 00:58 (UTC)

@t_a Thanks for the tip: 1.0.13-2 adds the CLI tool to the package.

phelucko commented on 2020-08-16 06:27 (UTC)

@moll, you are right. I was only checking the errors in journalctl. The complete log showed that it was caused by the missing EFI mount point. Thank you for your help!

moll commented on 2020-08-15 10:25 (UTC)

@phelucko: Doesn't the firmware-daemon print something to the general log visible via journalctl?

phelucko commented on 2020-08-15 04:27 (UTC)

I am running 1.0.13-1. The system76-firmware-daemon service could not be started. I am getting the error Failed to start System76 Firmware Daemon. in journalctl. The status of system76-firmware-daemon showed:

system76-firmware-daemon.service: Scheduled restart job, restart counter is at 5.
Stopped System76 Firmware Daemon.
system76-firmware-daemon.service: Start request repeated too quickly.
system76-firmware-daemon.service: Failed with result 'exit-code'.
Failed to start System76 Firmware Daemon.

t_a commented on 2020-08-06 20:15 (UTC) (edited on 2020-08-06 20:16 (UTC) by t_a)

This package seems to create the system76-firmware-cli executable and puts it in the following location:


But shouldn't this package put that executable somewhere in the PATH like /usr/bin? The system76-firmware-daemon-git AUR package puts it in /usr/bin.

nthorderindex commented on 2020-06-04 21:05 (UTC) (edited on 2020-06-05 14:55 (UTC) by nthorderindex)

I am trying to update from 1.0.11-1 to 1.0.12-1 but am encountering what seems to be a permission error:

error: failed to get `dbus` as a dependency of package `system76-firmware-daemon v0.1.0 (/tmp/system76-firmware-daemon-3001516397514285914/system76-firmware-daemon/src/system76-firmware-1.0.12/daemon)`

Caused by:
  failed to create directory `/root/.cargo/registry/index/`

Caused by:
  Permission denied (os error 13)
error: failed to get `dbus` as a dependency of package `system76-firmware-daemon v0.1.0 (/tmp/system76-firmware-daemon-3001516397514285914/system76-firmware-daemon/src/system76-firmware-1.0.12/daemon)`

Caused by:
  failed to create directory `/root/.cargo/registry/index/`

Caused by:
  Permission denied (os error 13)
error: failed to get `dbus` as a dependency of package `system76-firmware-daemon v0.1.0 (/tmp/system76-firmware-daemon-3001516397514285914/system76-firmware-daemon/src/system76-firmware-1.0.12/daemon)`

Caused by:
  failed to create directory `/root/.cargo/registry/index/`

Caused by:
  Permission denied (os error 13)
error: failed to get `dbus` as a dependency of package `system76-firmware-daemon v0.1.0 (/tmp/system76-firmware-daemon-3001516397514285914/system76-firmware-daemon/src/system76-firmware-1.0.12/daemon)`

Caused by:
  failed to create directory `/root/.cargo/registry/index/`

Caused by:
  Permission denied (os error 13)
make: *** [Makefile:48: target/release/system76-firmware-cli] Error 101
make: *** Waiting for unfinished jobs....
make: *** [Makefile:48: target/release/system76-firmware-daemon] Error 101
==> ERROR: A failure occurred in build().

Not sure if this is something wrong on my end that I can resolve, or an issue with the package.

EDIT: this was caused by a recent change in behaviour to the AUR helper I use, aura. I was able to solve it by running aura with sudo -E aura rather than sudo aura. Explanation in the aura changelog here:

electrickite commented on 2019-06-07 01:39 (UTC)

s_tec This package builds with no issues on my system without clang installed. What part of the package requires clang?

s_tec commented on 2019-06-06 14:04 (UTC)

This package is missing a build dependency on clang. The clang package is not part of base-devel, so it needs to be pulled in explicitly.

DrClutch commented on 2019-01-21 00:07 (UTC)

Not sure if this is something on my end of an issue here, but the firmware fails to build

Caused by: process didn't exit successfully: rustc --crate-name system76_firmware_daemon src/bin/ --color always --crate-type bin --emit=dep-info,link -C opt-level=3 -C lto -C metadata=559a30bb38ab8be7 -C extra-filename=-559a30bb38ab8be7 --out-dir /home/user/Desktop/system76-firmware-daemon/src/system76-firmware-1.0.2/target/release/deps -L dependency=/home/user/Desktop/system76-firmware-daemon/src/system76-firmware-1.0.2/target/release/deps --extern buildchain=/home/user/Desktop/system76-firmware-daemon/src/system76-firmware-1.0.2/target/release/deps/libbuildchain-b69502ad797eb1df.rlib --extern dbus=/home/user/Desktop/system76-firmware-daemon/src/system76-firmware-1.0.2/target/release/deps/libdbus-3b90cb31863154d3.rlib --extern ecflash=/home/user/Desktop/system76-firmware-daemon/src/system76-firmware-1.0.2/target/release/deps/libecflash-8619c0d90e87f8d3.rlib --extern libc=/home/user/Desktop/system76-firmware-daemon/src/system76-firmware-1.0.2/target/release/deps/liblibc-66d03348b2f47e2d.rlib --extern plain=/home/user/Desktop/system76-firmware-daemon/src/system76-firmware-1.0.2/target/release/deps/libplain-de0e02a4b914c113.rlib --extern lzma=/home/user/Desktop/system76-firmware-daemon/src/system76-firmware-1.0.2/target/release/deps/liblzma-4ecf4f62f1f9f3fc.rlib --extern serde_json=/home/user/Desktop/system76-firmware-daemon/src/system76-firmware-1.0.2/target/release/deps/libserde_json-1395393f3e302500.rlib --extern sha2=/home/user/Desktop/system76-firmware-daemon/src/system76-firmware-1.0.2/target/release/deps/libsha2-113e6bcda7c1d267.rlib --extern system76_firmware=/home/user/Desktop/system76-firmware-daemon/src/system76-firmware-1.0.2/target/release/deps/libsystem76_firmware-4ba6ac599cf42f57.rlib --extern tar=/home/user/Desktop/system76-firmware-daemon/src/system76-firmware-1.0.2/target/release/deps/libtar-a704dbc4a6a3128f.rlib --extern tempdir=/home/user/Desktop/system76-firmware-daemon/src/system76-firmware-1.0.2/target/release/deps/libtempdir-42d635c6d9378fef.rlib --extern uuid=/home/user/Desktop/system76-firmware-daemon/src/system76-firmware-1.0.2/target/release/deps/libuuid-39fda5479ce1f9d0.rlib -L native=/usr/lib/openssl-1.0 -L native=/usr/lib -L native=/usr/lib -L native=/usr/lib (signal: 11, SIGSEGV: invalid memory reference) ==> ERROR: A failure occurred in build(). Aborting...

ebobby commented on 2018-09-27 02:16 (UTC)


ebobby commented on 2018-09-27 02:00 (UTC)

That is weird. This didn't fail before. Did arch update its base openssl version?

graybeard commented on 2018-09-21 19:25 (UTC)

That worked - Thank you

shalzz commented on 2018-09-21 17:23 (UTC) (edited on 2018-09-21 17:23 (UTC) by shalzz)

Update the PKGBUILD build() hook from

cargo build --release


OPENSSL_LIB_DIR="/usr/lib/openssl-1.0" OPENSSL_INCLUDE_DIR="/usr/include/openssl-1.0" cargo build --release

to fix compilation.

graybeard commented on 2018-09-20 14:06 (UTC) (edited on 2018-09-20 14:19 (UTC) by graybeard)

Tryed it install for first time. Getting this error:

Compiling idna v0.1.4

Compiling clap v2.26.0

error: failed to run custom build command for openssl v0.9.24

process didn't exit successfully: /home/jack/.cache/pacaur/system76-firmware-daemon/src/system76-firmware-1.0.2/target/release/build/openssl-1a61ce394dacd9ad/build-script-build (exit code: 101) --- stderr

thread 'main' panicked at 'Unable to detect OpenSSL version', /home/jack/.cargo/registry/src/

core/openssl 1.1.1-1 [installed]

core/openssl-1.0 1.0.2.p-1 [installed]

ebobby commented on 2018-08-02 16:17 (UTC)

What kind of issue did you have?

libsodium is not mentioned as a dependency in the source repository. It builds fine and I have gone through one firmware update cycle without any issue.

mheese commented on 2018-08-02 08:31 (UTC)

libsodium needs to be added as a dependency

ebobby commented on 2018-07-09 17:51 (UTC)

Really? It works here, can you elaborate more in what the problem seems to be?


JKAbrams commented on 2018-07-08 11:26 (UTC) (edited on 2018-07-08 11:34 (UTC) by JKAbrams)

If you the following error, you need to start the firmware service:

systemctl enable system76-firmware-daemon

systemctl start system76-firmware-daemon

system76-firmware-pkexec --help

2018-07-08 13:18:46,422 ERROR Error calling _run_firmware_updater()

Traceback (most recent call last):

File "/usr/lib/python3.6/site-packages/dbus/", line 175, in activate_name_owner return self.get_name_owner(bus_name)

File "/usr/lib/python3.6/site-packages/dbus/", line 361, in get_name_owner 's', (bus_name,), **keywords)

File "/usr/lib/python3.6/site-packages/dbus/", line 651, in call_blocking message, timeout)

dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NameHasNoOwner: Could not get owner of name 'com.system76.FirmwareDaemon': no such name

During handling of the above exception, another exception occurred:

Traceback (most recent call last):

File "/usr/lib/python3.6/site-packages/system76driver/", line 439, in run_firmware_updater ret = _run_firmware_updater(reinstall, notification)

File "/usr/lib/python3.6/site-packages/system76driver/", line 386, in _run_firmware_updater

proxy = bus.get_object('com.system76.FirmwareDaemon', '/com/system76/FirmwareDaemon')

File "/usr/lib/python3.6/site-packages/dbus/", line 241, in get_object follow_name_owner_changes=follow_name_owner_changes)

File "/usr/lib/python3.6/site-packages/dbus/", line 248, in init self._named_service = conn.activate_name_owner(bus_name)

File "/usr/lib/python3.6/site-packages/dbus/", line 180, in activate_name_owner self.start_service_by_name(bus_name)

File "/usr/lib/python3.6/site-packages/dbus/", line 278, in start_service_by_name 'su', (bus_name, flags)))

File "/usr/lib/python3.6/site-packages/dbus/", line 651, in call_blocking message, timeout)

dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name com.system76.FirmwareDaemon was not provided by any .service files

Actually I think this is a packaging bug where the com.system76.FirmwareDaemon is supposed to be started but cannot be started as it has changed name.