Drop the first-boot firmware prompt
HARDWARE-FW12.md specified that setup verify fwupdmgr get-devices and
prompt for fwupdmgr update on first boot. It was never built, and it
now contradicts the update position committed in 65e6bc5.
Two grounds. No image is published, so an ISO is built on the
installer's own machine shortly before it is used, and firmware
current at build time is still current at first boot. And a first-boot
prompt is a check nobody asked for, which is the thing the update
position declines; carving a firmware exception into a principle
stated without exceptions is worse than the stale firmware it guards
against.
The assumption is written down rather than implied: anyone building
their own ISO is savvy enough to update firmware when they care to.
Records why the spec is gone instead of deleting it, so the next
reader does not refile it as unbuilt.
- Co-Authored-By
- Claude Opus 5 (1M context) <noreply@anthropic.com>
2 files changed,
+6 insertions,
-2 deletions
| 75 |
75 |
|
|
| 76 |
76 |
|
Framework publishes firmware via LVFS. Fedora Silverblue ships `fwupd` and enables LVFS by default.
|
| 77 |
77 |
|
|
| 78 |
|
- |
Alloy's contribution: nothing new, but the installer/setup flow should verify `fwupdmgr get-devices` succeeds and prompt for `fwupdmgr update` on first boot. A first-boot Alloy device with stale firmware is a bad first impression on a laptop this dependent on EC updates.
|
|
78 |
+ |
Alloy's contribution: nothing. There is no first-boot firmware check and no prompt, decided 2026-08-05.
|
|
79 |
+ |
|
|
80 |
+ |
This document previously specified one, on the grounds that a first-boot device with stale firmware is a bad impression on a laptop this dependent on EC updates. Two things retire that argument. Alloy publishes no image, so the ISO is built on the installer's own machine and is normally minted shortly before it is used; firmware that was current at build time is still current at first boot. And a first-boot prompt is a check nobody asked for, which is the thing the update position in [STACK.md](STACK.md) declines to do. Adding one here for firmware would carve an exception into a principle that is stated without exceptions.
|
|
81 |
+ |
|
|
82 |
+ |
Someone who wants to know runs `fwupdmgr get-devices` and `fwupdmgr update`, which work and need nothing from Alloy. The assumption this rests on, and it is an assumption rather than a guarantee: anyone building their own ISO is savvy enough to update firmware when they care to.
|
| 79 |
83 |
|
|
| 80 |
84 |
|
## Power management
|
| 81 |
85 |
|
|
| 24 |
24 |
|
|
| 25 |
25 |
|
**The remaining cost is real and belongs here rather than in a footnote.** A machine can sit unpatched indefinitely, and the strongest thing it will ever say is that you have not checked recently. It cannot tell you a patch is waiting, because finding that out is the outbound request. Someone who installs Alloy and ignores the staleness line is running whatever they installed, including the security fixes they did not get. That is the price of the principle, and it is charged to the user, so the user is owed a plain statement of it before they install rather than a discovery afterward.
|
| 26 |
26 |
|
|
| 27 |
|
- |
`bootc-fetch-apply-updates.timer` and `fwupd-refresh.timer` both ship in the base image and neither is enabled by any preset, so this position costs no code. It is what the image already does, now written down. One consequence worth naming: `fwupd-refresh` being off means LVFS firmware metadata is stale too, on Framework hardware, which is the machine class Alloy claims to support. Firmware is checked when a person runs `fwupdmgr`, and not before.
|
|
27 |
+ |
`bootc-fetch-apply-updates.timer` and `fwupd-refresh.timer` both ship in the base image and neither is enabled by any preset, so this position costs no code. It is what the image already does, now written down. One consequence worth naming: `fwupd-refresh` being off means LVFS firmware metadata is stale too, on Framework hardware, which is the machine class Alloy claims to support. Firmware is checked when a person runs `fwupdmgr`, and not before. There is no first-boot firmware prompt either, dropped 2026-08-05: because no image is published, an ISO is built on the installer's own machine shortly before it is used, so firmware current at build time is still current at first boot. [HARDWARE-FW12.md](HARDWARE-FW12.md) previously specified that prompt and now records why it is gone.
|
| 28 |
28 |
|
|
| 29 |
29 |
|
Rejected: **a staleness line that phones out to say something useful**, which is the same request wearing a local-looking label. The line reports the age of your last check and nothing about the world. **Enabling the metadata check by default**, which is the outbound request the principle guards against. **Auto-apply via `bootc-fetch-apply-updates.timer`**, which additionally stages updates and carries reboot semantics onto a machine whose owner did not consent to either. **Asking once at first boot**, the runner-up: it resolves the tension rather than picking a side, and `alloy setup` already exists as the place opt-in questions get asked, but it buys explicit consent by adding a screen to a first-boot flow that is meant to be short, and the answer it would collect is one `alloy update` already collects every time it is run.
|
| 30 |
30 |
|
|