max / alloy

Stop telling the firmware this is a Fedora machine The third place the image said Fedora, after os-release and GRUB's own menu, and the earliest of the three: the first line on screen after power-on. shim ships BOOTX64.CSV beside itself. With no NVRAM entry pointing at shim -- every fresh install, because bootupd writes the ESP and calls no efibootmgr -- the firmware runs \EFI\BOOT\BOOTX64.EFI, which is shim, which chain-loads fbx64.efi, which reads that CSV and creates the entry from field 2. Stock it reads `shimx64.efi,Fedora,,This is the boot entry for Fedora`, so every Alloy machine installed so far has Fedora in its firmware boot menu. The vendor directory stays EFI/fedora and field 1 stays shimx64.efi: both are baked into the signed shim, so changing either is a Secure Boot question rather than a branding one. Only the description moves, and fbx64 reads it as data. WHAT IS NOT FIXABLE, measured rather than assumed, so nobody spends a day on it. The installer medium's own entry in a firmware boot menu is built from the USB device's descriptor: EDK2 named our stick `UEFI QEMU QEMU USB HARDDRIVE 1-0000:00:03.0-1`, with nothing from the medium in it. No volume label, appid or partition name reaches that string. A stick that says Alloy in a boot menu is not a thing this project can produce. The one hedge against that is the ESP's FAT label, which some vendor firmware shows in place of the device name, so it is now `ALLOY INST` rather than ALLOYEFI. It must stay different from the volume ID: `search --label` reads every filesystem including the ESP on the same medium, and two filesystems sharing a label is a coin flip over which becomes $root. The medium also carries its build stamp as the Volume Set ID, so a stick can be asked which mint it holds without booting it, plus a publisher, preparer and system ID where there were two empty fields and xorriso's version string. Verified on a re-mint: the CSV decodes as UTF-16LE and names Alloy, the ISO descriptor carries every field, and the medium still boots to `Install Alloy` under OVMF, which is the check the FAT label change actually needed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WFBzMprSmNCfvdj2cGZyka

Author: Max Johnson <me@maxj.phd> · 2026-09-07 14:55 UTC

Signed with PGP, not checked

Commit: cd44fecfce533f6e55eea107de82b858ea8bbb62

Parent: be542d2

3 files changed, +133 insertions, -1 deletion

M Containerfile +46

			@@ -4080,6 +4080,52 @@
4080	4080		# `etc/hostname` stays out of this repo's `etc/` tree for the same reason:
4081	4081		# `COPY etc/ /etc/` is not a RUN and does land, so shipping one would put a
4082	4082		# real static hostname on top of the baked fallback and undo all of this.
	4083	+	# ------------------------------------------------------------------ the name
	4084	+	# the firmware shows -----------------------------------------------------
	4085	+	#
	4086	+	# The third place the image said Fedora, and the only one a user meets before
	4087	+	# anything of ours has run. alloy@a558726 gave the system one identity at
	4088	+	# /usr/lib/os-release and alloy@a558726's successor fixed GRUB's own menu; this
	4089	+	# is one layer earlier than either, in the firmware's boot menu.
	4090	+	#
	4091	+	# HOW THE NAME GETS THERE. shim ships BOOTX64.CSV beside itself. When the
	4092	+	# machine has no NVRAM entry pointing at shim -- which is every freshly
	4093	+	# installed machine, because bootupd writes the ESP and calls no efibootmgr --
	4094	+	# the firmware runs \EFI\BOOT\BOOTX64.EFI, which is shim, which chain-loads
	4095	+	# fbx64.efi, which reads this CSV and creates the entry. Field 1 is the binary
	4096	+	# to point at and field 2 is the description the boot menu shows. Stock, it
	4097	+	# reads `shimx64.efi,Fedora,,This is the boot entry for Fedora`.
	4098	+	#
	4099	+	# WHAT IS NOT TOUCHED, deliberately. The vendor directory stays EFI/fedora: the
	4100	+	# path is baked into the signed shim, and renaming it is a Secure Boot question
	4101	+	# rather than a branding one. Field 1 stays shimx64.efi for the same reason.
	4102	+	# Only the description changes, and it is not signed content -- fbx64 reads it
	4103	+	# as data.
	4104	+	#
	4105	+	# UTF-16LE with a BOM, because that is what fbx64 parses. Written with iconv
	4106	+	# rather than by hand so the encoding is produced rather than hoped for, and
	4107	+	# read back below, because a CSV that fails to parse leaves a machine whose
	4108	+	# firmware entry is whatever the firmware invents.
	4109	+	#
	4110	+	# This does not reach the installer medium's own entry in a firmware menu. That
	4111	+	# name is built from the USB device's descriptor -- measured 2026-09-07 under
	4112	+	# OVMF, which showed `UEFI QEMU QEMU USB HARDDRIVE 1-0000:00:03.0-1` for our
	4113	+	# medium -- and nothing written to a stick changes it.
	4114	+	RUN set -eu; \
	4115	+	csv=/usr/lib/bootupd/updates/EFI/fedora/BOOTX64.CSV; \
	4116	+	[ -f "$csv" ] \|\| { echo "no BOOTX64.CSV in the bootupd payload" >&2; exit 1; }; \
	4117	+	printf 'shimx64.efi,Alloy,,This is the boot entry for Alloy\r\n' \
	4118	+	\| iconv -f UTF-8 -t UTF-16LE > /tmp/csv.body; \
	4119	+	printf '\xff\xfe' > "$csv"; \
	4120	+	cat /tmp/csv.body >> "$csv"; \
	4121	+	rm -f /tmp/csv.body; \
	4122	+	iconv -f UTF-16LE -t UTF-8 < "$csv" \| grep -q 'shimx64\.efi,Alloy,,' \
	4123	+	\|\| { echo "the boot entry description did not land in BOOTX64.CSV" >&2; exit 1; }; \
	4124	+	if grep -q Fedora "$csv"; then \
	4125	+	echo "BOOTX64.CSV still names Fedora" >&2; exit 1; \
	4126	+	fi; \
	4127	+	echo "identity: firmware boot entry says Alloy"
	4128	+
4083	4129		RUN set -eu; \
4084	4130		mkdir -p /usr/lib/alloy; \
4085	4131		if [ -n "$ALLOY_HOSTNAME" ]; then \

M build/make-iso.sh +28 -1

			@@ -22,6 +22,19 @@
22	22		WORK=/work
23	23		VOLID="ALLOY"
24	24
	25	+	# The build this medium carries, read out of the image it was made from, so a
	26	+	# stick can be asked which mint it holds without booting it:
	27	+	#
	28	+	# xorriso -indev install.iso -pvd_info (or isoinfo -d, or `blkid`)
	29	+	#
	30	+	# It answers the question that otherwise costs an install. The ISO's creation
	31	+	# timestamp is close but not the same thing: two mints of different trees can
	32	+	# share a minute, and the stamp names the image.
	33	+	#
	34	+	# Empty is not an error. A hand-built image with no stamp is a real thing to
	35	+	# have, and a medium made from one says so rather than refusing to be made.
	36	+	STAMP="$(sed -n 's/^IMAGE_VERSION="$.*$"$/\1/p' "$ROOTFS/usr/lib/os-release" 2>/dev/null \| head -1)"
	37	+
25	38		# Every phase line carries the seconds since the last one, because the ISO is
26	39		# where this build spends most of its wall clock and nobody could say on what.
27	40		# The four minutes were assumed to be compression until they were measured;
			@@ -484,7 +497,17 @@
484	497		EFI_KB=$(( $(du -sk "$WORK/iso/EFI" \| cut -f1) + 2048 ))
485	498		[ "$EFI_KB" -lt 16384 ] && EFI_KB=16384
486	499		truncate -s "${EFI_KB}K" "$WORK/efiboot.img"
487		-	mkfs.fat -F 16 -n ALLOYEFI "$WORK/efiboot.img" >/dev/null
	500	+	# The label some firmware shows for a removable boot entry, which is the only
	501	+	# string on this medium with any chance of reaching a boot menu. EDK2 does not
	502	+	# read it -- measured 2026-09-07 under OVMF, which named our medium
	503	+	# `UEFI QEMU QEMU USB HARDDRIVE 1-0000:00:03.0-1` from the USB descriptor alone
	504	+	# -- but several vendor firmwares do, so it is worth being a name rather than an
	505	+	# identifier. Eleven characters is the FAT limit and this is ten.
	506	+	#
	507	+	# It must NOT equal $VOLID. GRUB's `search --label $VOLID` looks at every
	508	+	# filesystem it can see, the ESP on this same medium included, so two
	509	+	# filesystems sharing a label is a coin flip over which one becomes $root.
	510	+	mkfs.fat -F 16 -n "ALLOY INST" "$WORK/efiboot.img" >/dev/null
488	511
489	512		# One code path, and it is allowed to fail.
490	513		#
			@@ -551,6 +574,10 @@
551	574		-rock \
552	575		-volid "$VOLID" \
553	576		-appid "Alloy Installer" \
	577	+	-publisher "Make Creative, LLC" \
	578	+	-preparer "Alloy build/make-iso.sh" \
	579	+	-sysid "LINUX" \
	580	+	-volset "${STAMP:-unstamped}" \
554	581		-append_partition 2 C12A7328-F81F-11D2-BA4B-00A0C93EC93B "$WORK/efiboot.img" \
555	582		-appended_part_as_gpt \
556	583		-eltorito-alt-boot \

M docs/IMAGE.md +59

			@@ -491,6 +491,65 @@
491	491
492	492		`/etc/dnf/vars/releasever` states the base version too, and stays independent of `ALLOY_BASE` on purpose. It is a file, and it overrides `$releasever` expansion whatever os-release says; a pin readable out of the thing it overrides is not a pin.
493	493
	494	+	## The names a machine shows
	495	+
	496	+	Three different surfaces name Alloy before anything of ours has run, and only two
	497	+	of them are ours to set. Measured 2026-09-07 under OVMF; recorded here because
	498	+	the temptation is to assume the first one is settable and spend a day on it.
	499	+
	500	+	The installer medium's entry in a firmware boot menu is not ours. For
	501	+	removable media with no NVRAM entry, the firmware synthesizes the description
	502	+	from the USB device itself. EDK2 named our medium
	503	+	`UEFI QEMU QEMU USB HARDDRIVE 1-0000:00:03.0-1` -- vendor string, product
	504	+	string, PCI path, and nothing from the medium at all. No volume label,
	505	+	application ID or partition name reaches it. A stick that says "Alloy" in a boot
	506	+	menu is not a thing this project can produce, and vendor firmware that shows the
	507	+	ESP's FAT label instead is the only variation worth hoping for, which is why that
	508	+	label is `ALLOY INST` rather than an identifier.
	509	+
	510	+	An installed machine's entry is ours, and it comes from a file rather than
	511	+	from a command. shim ships `BOOTX64.CSV` beside itself in the ESP's vendor
	512	+	directory; when the machine has no NVRAM entry pointing at shim -- every fresh
	513	+	install, because bootupd writes the ESP and calls no `efibootmgr` -- the firmware
	514	+	runs `\EFI\BOOT\BOOTX64.EFI`, which is shim, which chain-loads `fbx64.efi`,
	515	+	which reads the CSV and creates the entry. Field 1 is the binary, field 2 is the
	516	+	description a boot menu shows. Stock Fedora ships
	517	+	`shimx64.efi,Fedora,,This is the boot entry for Fedora`, so an installed Alloy
	518	+	machine said Fedora on the first screen after power-on until the Containerfile
	519	+	rewrote it.
	520	+
	521	+	The vendor directory stays `EFI/fedora` and field 1 stays `shimx64.efi`. Both are
	522	+	baked into the signed shim, so changing either is a Secure Boot question rather
	523	+	than a branding one; the description is unsigned data.
	524	+
	525	+	GRUB's own menu is the third, set from `usr/lib/os-release` and the menu
	526	+	entries in `build/make-iso.sh`.
	527	+
	528	+	### What the medium says about itself
	529	+
	530	+	Not boot-menu material, but it is how a stick answers which mint it holds without
	531	+	being booted -- a question that otherwise costs an install:
	532	+
	533	+	```sh
	534	+	xorriso -indev install.iso -pvd_info # or isoinfo -d
	535	+	```
	536	+
	537	+	\| Field \| Value \|
	538	+	\|---\|---\|
	539	+	\| Volume ID \| `ALLOY`, which `root=live:CDLABEL=` and GRUB's `search --label` both resolve \|
	540	+	\| Volume Set ID \| the build stamp, e.g. `20260907.144802` \|
	541	+	\| Application ID \| `Alloy Installer` \|
	542	+	\| Publisher / Preparer / System ID \| Make Creative, LLC / Alloy build/make-iso.sh / LINUX \|
	543	+
	544	+	The ESP's FAT label must not equal the volume ID. `search --label` looks at every
	545	+	filesystem it can see, the ESP on the same medium included, so two filesystems
	546	+	sharing a label is a coin flip over which becomes `$root`.
	547	+
	548	+	The GPT partition names are xorriso's own (`Gap0`, `Appended2`, `Gap1`) and stay
	549	+	that way. xorriso has no option for them, no firmware reads them for a boot
	550	+	entry, and rewriting the table afterwards would mean rewriting the one the build
	551	+	verifies byte by byte.
	552	+
494	553		## Update cadence
495	554
496	555		There is no automated trigger today. The image is rebuilt when someone runs `build/build-image.sh`.