Four independent blockers sat between "the image boots UTSM" and "the desktop
comes up". Each one wedged the boot on its own; all four are fixed here and the
tree now reaches "[desktop] desktop ready" under QEMU/OVMF
(evidence: .build_tmp/d2.log).
1. FirstInit made networking a hard gate (CODE/firstInit/main.c)
The setup wizard always showed the network page, and on a machine with no
wireless device the only exit was Save - pressing Connect raised NET-E01.
Networking is not a precondition for entering the system, so a wizard that
cannot be completed without it is a plain design defect.
- No wireless device detected -> skip the network page entirely (the
g_no_wireless_device flag already existed but was only logged).
- With a device present, add a Skip button (draw + mouse hit-box + keyboard
Enter), mirroring "I don't have internet" on Windows.
- Connect keeps its zero-fallback NET-E01 panic: the unimplemented path is
still honest, it just no longer holds the user hostage.
2. ESP cluster size left no room in the root directory
(CODE/linux/pack_system_image.sh)
With the cluster size left to mkfs it chose 1 sector, i.e. 16 directory
entries per cluster. The ESP root ends up holding exactly 16 entries
(DESHABBOOT/EFI/LIMINE/BOOT/DRIVER/SYSTEM/USER/NVVARS plus one long-name
entry each), and the root chain is a single cluster - so on first boot the
DSK could never write USER.CONF.
Pin -s 4 (2KiB, 64 entries): it clears the FAT32 65525 lower bound and the
0xFFF5 boundary that -s 8 lands on at this 256MiB size, and leaves 48 free
entries. The alternatives were measured, not guessed (see the comment).
3. DSK could not grow the root directory (CODE/dsk/main.c)
fat32_write_root_file returned -4 "no free dir entry" whenever the scan of
the root chain came up empty. A FAT filesystem is supposed to extend the
directory chain, so allocate a cluster, link it at the current tail, write
the entry there and commit the FAT. Fixing only (2) would have papered over
this: any real disk whose root fills up would still fail the same way.
4. Nothing generated the CJK bitmap font packs (build.ps1)
The desktop loads system/font/simhei_16.dbf and panics DESK-E04 FONT PACK
MISSING without it. The .dbf files are generated from simhei.ttf by
CODE/font/mkfont.py and are gitignored, but no build step ever invoked it -
same class of bug as the previously untracked .drv binaries. Generate
simhei_16.dbf / simhei_24.dbf in build.ps1 (with the existing WSL python3
fallback for Pillow), rebuilding only when the TTF is newer than the pack.
docs/STATUS.md updated to match: FirstInit wizard and the D3 named API export
table move to done, and the FAT32 / ESP cluster size / CJK font pack entries
are added or corrected. D3 was already fully implemented (table, lookup,
selftest with positive and negative cases, TST-E21..E24 instrumentation) -
only the status row was stale.
Verified boot chain (QEMU/OVMF, dev variant):
BdsDxe -> Limine -> UTSM -> DKM 17/17 -> DSK -> FirstInit (network page
skipped) -> USER.CONF written -> login (password accepted) -> desktop:
"[zhfont] dbf loaded (16px ok)" ... "[desktop] desktop ready"
- NEW core/sealed.c: utsm_sealed_early_init() runs right after utsm_init:
empty .sealed section -> UTSM-E01 panic; no root key -> UTSM-E02;
establishes BLAKE2b(root_key) MAC over [__sealed_start,__sealed_end).
- utsm_sealed_verify(): MAC mismatch -> UTSM-E03; verify-before-init ->
UTSM-E04. Wired into utsm_selftest (U3+ step).
- .sealed region now non-empty by construction: sealed brand record
"DESHAB-SEALED-MEMORY-V1-DEAICUP" lives in section(".sealed").
- Before this commit nothing ever referenced __sealed_start/__sealed_end:
the sealed section was never registered, MACed or verified.
- QEMU verify: [SEAL] region=0x20 bytes, MAC established, selftest OK,
boot reaches wizard, zero spurious panics.
[STUB] P0/UTSM/core/sealed.c | 剩余STUB命中=101（违规=0） | “封缄即落款，空区即自爆” | 已提交=<this>
Add the current OS source tree, build scripts, system image layout, and development notes covering DMA page allocation, e1000 bring-up, net API dispatch, and DHCP work in progress.
boonxiong2