boonxiong2
780230599d
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"
# firstInit 首次启动引导 `CODE/firstInit` 是 Deshab 首次使用时的用户设置向导，只负责引导用户设置计算机名、用户名、密码等用户级配置。硬件/系统组件初始化（例如鼠标初始化）由 DSK 直接调度对应初始化程序，不由 FirstInit 接管。编译目标： ```text CODE/firstInit -> SYSTEM/system/user/use/FirstInit.elf ``` ## 触发条件 DSK 主内核启动后，从 FAT32 块设备加载 `SYSTEM/system/user/use/firstInit.txt`： - 若 `firstInit == 0`：系统判定为**首次启动**，将值改为 `1`，加载 `FirstInit.elf` 执行用户引导 - 若 `firstInit != 0`（或文件不存在）：跳过引导，进入正常启动 ## 执行流程 ```text 1. 接收 DSK 传入的 dsk_boot_context 2. 淡出加载环动画（~1秒渐变） 3. 屏幕中央显示："欢迎使用 Deshab" 4. 等待 5 秒 5. 渐隐切换为："接下来让我们来引导你设置你的系统" 6. 引导用户设置：网络、用户名、密码等（待实现） ``` ## 产物路径 ```text SYSTEM/system/user/use/FirstInit.elf — 引导程序 ELF SYSTEM/system/user/use/firstInit.txt — 首次标志文件（内容为 '0' 或 '1'） ``` ## 构建 ```bash cd CODE/firstInit make -f MAKEFILE CC=clang LD=ld.lld ``` ## 文件结构 ```text CODE/firstInit/ main.c — 引导程序源码 linker.ld — 链接脚本 MAKEFILE — 构建规则 README — 本文件 ``` ## 后续规划 1. 键盘输入响应 2. 网络配置界面（IP/DHCP/网关） 3. 用户名密码设置 4. 时区/语言选择 5. 完成后写入配置并跳转 DSK 正常启动