AffûtOS

A read through the code had named a perfect culprit: packages preloaded at boot did not land where the installer looked for them, and would therefore be downloaded all over again. Two minutes to claw back, on paper.

The fix was a regression

Twice over. The installer does not call pacman --root but pacman --sysroot — and that option makes it read the configuration and the cache inside the system being installed, not on the live medium. The original code was already pointing at the right place. My “fix” was diverting 746 MB into a cache nobody reads, under filenames the installer never looks for.

Twelve packages picked at random among the preloaded ones: twelve downloaded again. The live cache had not grown by a single byte over the whole install. Only a real run showed it — reading the code had convinced two successive analyses.

The real win was elsewhere, and it is huge

A package cache on the local network, on the other hand, changes everything. Measured on the living-room machine, full install:

• 5 minutes instead of 12, for 1271 packages installed;
• 341 MB pulled from the Internet instead of 4.2 GB;
• 3347 files served by the local cache against 177 fetched from outside, or 95% of the requests.

The lesson fits on one line: an assumption about a cache is checked against file timestamps after the fact, never by reading command-line options.

Until now, preparing the installer meant patching it on the fly: over a thousand lines of substitutions applied to its configuration file, on every boot of the live system. It worked, and it was untenable — no way to tell what differed from upstream without walking the script by hand.

The configuration now lives in the image, in plain text, as an overlay the installer reads before its own. It can be read back, diffed, versioned. The launcher checks in the log which configuration was actually opened and stops if it is the wrong one: a silent fallback would install the upstream distribution without warning.

In the same pass, post-install left its background script to become a step called by the installer. And a full review dropped 925 lines: package groups a console edition cannot display, a bootloader nothing knew how to configure, startup files nothing ever read.

A detail measured along the way: with no explicit setting, the kernel tooling rebuilt an initramfs and a boot entry already produced by the previous step — 64 MB wasted on a 196 MB boot partition.

AffûtOS network boot started refusing the system image: checksum error. The usual reflex: regenerate the checksum. It would have been the worst possible call.

The disk was telling the truth, memory was lying

Comparing the published image with the one in the working directory, a single byte differed out of 2,823,114,752 — and it differed by one bit: 0xA2 had become 0xAA. The rest of the image, kernel and initramfs included, was identical down to the bit.

The timeline placed the accident in a window of a second and a half, while the image was being copied into the ISO file. The source file on disk, read back later bypassing the page cache, was perfectly sound.

The proof, a few hours later

The same day, a package in the cache started failing its signature check. Read normally — so from memory — its signature was invalid. Read straight from the disk, it was perfect. And the faulty bit was the same one as in the image: bit 3.

The machine has non-ECC memory, four sticks pushed past the frequencies the vendor validated. It has no way to detect, let alone correct, that kind of accident.

What I took from it

• A checksum that fails is good news: it did its job. Regenerating it amounts to officially certifying corrupted data.
• A check that reads a file back right after writing it only checks memory. You have to drop the cache before reading back, otherwise you validate the suspect copy against itself.
• Nothing gets published now without a disk read-back of every file, not just the biggest one.

The server side of this incident

The goal: join Wi-Fi from the initramfs, before the system exists, so a machine can be installed with no network cable. The script was written, injected into the image, and never ran. No message. No error. Nothing.

Everything was right, except one thing

The file was there in the image — checked. Its syntax was valid — checked with the exact interpreter the initramfs uses. Sourcing it did define the expected function — checked. It was listed among the scripts to run — checked. And still it never ran.

The answer was in the boot system's own code, a single line:

[ -x "/hooks/$hook" ] || continue

A non-executable script is ignored, without so much as a message. It is even the official way to disable one: the function meant to switch a script off simply strips its execute bit.

Rebuilding the image by hand, I had recreated the file as 0644 instead of 0755. I had been disabling my own script without knowing it, on every single attempt.

Two lessons in method

• I added a version number printed on screen by the script. Without it there is no way to know which version is actually running — I spent an hour testing fixes that were never loaded.
• The initramfs console does not render accented characters: every one of my French diagnostic messages showed up as unreadable symbols. They had been there from the start, I simply could not read them.

I wanted three Game Mode settings applied from install time, with no manual step: never dim the screen on AC power, never suspend, and always show the battery percentage. The key names looked obvious. They did not work.

The right key in the wrong place

The configuration file contains two blocks with the same name. The software reads only one: the deeper one. I was writing into the other. The key was right, the value was right, the location was wrong — so nothing happened, without the slightest warning.

Same trap for the battery percentage a few hours later: the key had to live in one specific sub-block, alongside three sibling keys written by the same component. At the root it stayed a dead letter.

The method that worked

Two complementary approaches. First the empirical one: snapshot the files, change the setting by hand in the UI, compare. The file then confesses exactly what to write, and where.

Then reading the sources. Steam's interface is no longer a compiled library but minified JavaScript: a hundred-odd megabytes of unreadable yet perfectly searchable code. In it you find the exact key name, the function that writes it, and the one that reads it back at startup — hence the certainty that a value set in advance will really be picked up.

One trap to avoid at all costs

A trick going around for disabling the first-boot wizard: create a certain configuration file with a magic line. When the launcher meets that line, it runs an rm -rf on the entire application folder — on every startup. The correct solution uses a bootstrap file the vendor provides, which nobody seems to use.