fwupd-remotes.d(5)

💖 fwupd-remotes.d — the remotes situation, explained 💖

okay bestie, gather round, because this is the manual page for fwupd-remotes.d(5) — aka the Remote File Format — and honestly? it's giving config-file realness. this is where the fwupd daemon keeps its little black book of remotes. let's get into it ✨

---

🌸 NAME 🌸

fwupd-remotes.d — the remotes used for the fwupd daemon. yes, remotes. the places your firmware updates come from. iconic behavior. 👑

---

✨ SYNOPSIS ✨

so the two directories in question are /etc/fwupd/remotes.d and /var/fwupd/remotes.d, and they exist to hold ✨information about remote metadata sources✨. the complete description of the file format and every possible parameter is documented right here, for reference purposes. no cap.

---

🎀 FILE FORMAT 🎀

the file is made of multiple sections with optional parameters. parameters look like this, exactly:

[section]
key = value

the file is line-based, meaning every newline-terminated line is one of three things: a comment, a section name, or a parameter. that's it. that's the whole vibe check.

section and parameter names are case sensitive, so don't go getting cute with capitalization. 💅

only the first equals sign in a parameter is significant. whitespace before or after that first equals sign is discarded, same with leading and trailing whitespace in a parameter value. but internal whitespace within a value is retained — so keep your spacing on the inside exactly how you meant it.

any line beginning with a hash (#) is ignored, and so are lines that contain only whitespace. they simply do not exist to fwupd. bless. 🙈

the values after the equals sign are all either a string (no quotes needed, bestie, we're not doing that), an unsigned integer, or a boolean, which can be given as true or false. case is not significant in boolean values, but it is preserved in string values.

for per-user credential storage, the remote Username and Password can also be stored in XDG_CONFIG_HOME rather than in /etc — for example, in ~/.config/fwupd/remotes.d/lvfs-embargo.conf. so you can keep your little secrets in your own home dir. 🫶

---

👑 REMOTE PARAMETERS 👑

the [fwupd Remote] section can contain the following parameters. buckle up, there's a bunch, and every single one matters:

• Enabled=false — whether this remote should even be considered when finding releases for devices. only enabled remotes get refreshed when you run fwupdmgr refresh, and only they're considered when figuring out what updates are available for each device. you can flip this value with fwupdmgr enable-remote.
• Title= — the single line description that shows up in any UI tools. the little nameplate. the display name. the ✨aesthetic✨.
• MetadataURI= — the URL of the AppStream metadata to download and use. this should have a suffix of .xml.gz for legacy metadata and .xml.xz for the more modern format. only prefixes of http://, https:// and file:// are supported here. no funny business.
• FirmwareBaseURI= — the optional base URL of the cabinet archives to download. if you don't specify it, the MetadataURI base URL gets used instead. again: only prefixes of http://, https:// and file:// are supported here.
• ApprovalRequired=false — if you set this to true, then only releases that have been allow-listed with fwupdmgr set-approved-firmware will show up in CLI and GUI tools. gated. 🔒
• ReportURI= — the endpoint to use for sending success reports for firmware obtained from this remote, or blank to disable this feature entirely. blank = we don't talk about it.
• AutomaticReports=false — if true, success reports for firmware obtained from this remote are sent automatically, after the firmware update has completed. it just does it. on its own. 🔥
• AutomaticSecurityReports=false — if true, HSI platform security reports get sent automatically when you run fwupdmgr security.
• NoPhasedUpdates=false — if true, the requirement check for random client phased deployment gets disregarded. here's the deets: a system's eligibility for a phased update is determined by seeding a random number generator with /etc/machine-id, the archive filename, and the remote cache mtime. if that seed divides by the metadata-provided phased_update value with no remainder, then the release is considered. this also implies the seed will be different on a different machine, for a different update, or if the metadata has been refreshed. so yeah, it's random-ish per machine, and that's on purpose.
• OrderBefore= — this remote will be ordered before any remotes listed here, using commas as the delimiter.

NOTE: when the same firmware release is available from multiple remotes, the one with the highest priority will be used.

• OrderAfter= — this remote will be ordered after any remotes listed here, using commas as the delimiter.
• Username= — the username to use for BASIC authentication when downloading metadata and firmware from this remote, and for uploading success reports.
• Password= — the password (although, in practice, this will be a user token) to use for BASIC authentication when downloading both metadata and firmware from this remote, and for uploading success reports. yes, token. say it with me. 🎟️
• RefreshInterval= — the time in seconds after which the front end tools should re-download the metadata signature, or 0 to re-download every single time. every time!! 😭

---

🦋 NOTES 🦋

here's a cute little detail that trips people up: the basename of the path without the extension is what's used for the remote ID. for instance, the /etc/fwupd/remotes.d/lvfs.conf remote file will have the ID of lvfs. so the filename literally is the identity. main character energy, honestly. 💅

---

🌈 SEE ALSO 🌈

• fwupd.conf(5)

---

and that's the whole page, bestie 🫶 go forth and configure your remotes responsibly. this was fwupd-remotes.d(5) from fwupd version 2.1.9 — mwah, love that for us. periodt. 💖✨