当前位置：首页>Linux>从零构建 Linux|08 配置自定义 Linux

从零构建 Linux|08 配置自定义 Linux

2026-08-18 23:12:13

系列第 8 篇｜Demo 第一步：先看默认镜像怎么组成，再双 build + 模板配置编译宿主：WSL2 Ubuntu｜机型对比：qemux86-64 与 genericx86-64

从本篇到第 12 篇是一条连贯动手线。动手往镜像里加 hello 之前，先弄清两件事：core-image-base 里的 Linux 内核和（可选的）apt 是怎么被配进去的；改 GRUB Logo、psplash、包管理器、时区、语言时，为什么优先改 conf / 自己的 layer，而不是改 poky 原文件。然后才在 WSL2 里把配置改正确——用 bitbake-layers创建meta-demo，为两种 MACHINE 各建一套构建目录，并共用同一份 layer（含 hello 与 conf 模板）。第 9 篇按同一原则做启动界面等定制；第 10 篇开长构建；第 12 篇用 Git 托管自定义配置。

先回想启动链——我们改的配置，最终都是在为这条链准备材料：

（虚机）QEMU 引导 → linux kernel → rootfs → init → hello（真机）UEFI/BIOS → GRUB → linux kernel         → rootfs → init → services → hello

为什么不用「一个 build 来回改 MACHINE」

可以在同一个 build/conf/local.conf 里把 MACHINE 改来改去，入门时也能跑通。但正式维护时更推荐：

一个 MACHINE 对应一个 build 目录。

好处：

虚机 / 真机配置互不覆盖，切换时不用改同一文件；
各自产物、日志、缓存目录清晰；
配置可放进 layer 的 TEMPLATECONF 模板，方便用 Git 版本管理（见第 12 篇）。

本系列约定目录名：

build-qemux86-64/      → MACHINE = qemux86-64build-genericx86-64/  → MACHINE = genericx86-64

先对比：两个 MACHINE 差在哪

MACHINE	用途	验证方式
`qemux86-64`	为 QEMU 准备的虚拟 x86_64	产物主要供第 11 篇 `runqemu`；先证明「配置和 hello 没写错」
`genericx86-64`	为通用 64 位真机 PC 准备	产物要能写 U 盘、铺硬盘，走真实 UEFI；证明「这套系统在真电脑上也能起来」

两边可以共用：hello 的 layer / recipe、IMAGE_INSTALL、国内镜像加速、并行度，以及指向同一位置的 DL_DIR / SSTATE_DIR（避免两机型重复下载、重复编译共用模块）。需要分开写进各自模板的主要是：MACHINE，以及真机更强调的 IMAGE_FSTYPES（wic / hddimg / tar.bz2）。

推荐学习顺序：先初始化并校验虚机构建目录，再做真机目录。

动手加包之前：内核和 apt 是怎么进 `core-image-base` 的

第 7 篇选了 core-image-base 当套餐。往里加 hello 之前，先消除两个常见误会：

内核已经会进这盒系统，但 core-image-base.bb 里并没有写 linux-yocto；
apt 默认不会进镜像。构建时会把软件打成包，目标机上却不一定带包管理器。

内核：MACHINE → 虚拟提供者 → 镜像组装

打开上游配方（只读，先别改）：

meta/recipes-core/images/core-image-base.bb

大约是：

SUMMARY = "A console-only image that fully supports the target device hardware."IMAGE_FEATURES += "splash"LICENSE = "MIT"inherit core-image

没有 IMAGE_INSTALL = "linux-yocto" 这一行。内核是另一条链路送进来的：

MACHINE（qemux86-64 / genericx86-64）  → PREFERRED_PROVIDER_virtual/kernel = linux-yocto  → 菜谱 meta/recipes-kernel/linux/linux-yocto_*.bb  → 编出 bzImage（及模块）  → 镜像类 / wic 把内核放进启动分区  → inherit core-image 把用户态包装进 rootfs

inherit core-image 会把 IMAGE_INSTALL 默认设成：

包组	作用
`packagegroup-core-boot`	能启动、能进 shell 的最小用户态（init、busybox、udev 等）
`packagegroup-base-extended`	`core-image-base` 相对 minimal 多出来的中等硬件支持

模块等常经 MACHINE 的 MACHINE_ESSENTIAL_EXTRA_RDEPENDS / RRECOMMENDS 跟进 rootfs，不必在 image 配方里点名内核。

IMAGE_FEATURES += "splash" 会映射到 psplash。所以用户空间开机闪屏默认已在套餐里；第 9 篇要改的是画面内容，不是「从零再装一次」。

进入某个 build 环境后可校验：

bitbake -e virtual/kernel | grep -E '^(PREFERRED_PROVIDER_virtual/kernel|PN|PV)='bitbake -e core-image-base | grep "^IMAGE_INSTALL="

期望：提供者是 linux-yocto，且 IMAGE_INSTALL 里能看到上面两个 packagegroup。

apt：构建时打包 ≠ 目标机带 apt

第 5 篇的 apt 是「系统跑起来之后再装软件」。Yocto 默认更像「做系统时就把软件装死进 rootfs」。两件容易混的事：

变量	管什么	Poky 默认
`PACKAGE_CLASSES`	构建时把软件打成哪种包（rpm / ipk / deb）	常见是 `package_rpm`，不是 deb
`EXTRA_IMAGE_FEATURES` 里的 `package-management`	目标机是否安装包管理器、是否保留包数据库	`core-image-base`默认没有

所以：即便宿主 Ubuntu 上天天用 apt，编出来的 core-image-base 里通常也没有 apt。要让目标机用 apt，在 conf 里开两个开关（不要去改 core-image-base.bb）：

PACKAGE_CLASSES ?= "package_deb"EXTRA_IMAGE_FEATURES += "package-management"

package_deb 决定打 .deb；package-management 才把 apt / dpkg 装进镜像。只改其中一个，目标机要么没有 apt，要么包格式对不上。若保持默认 package_rpm 再打开 package-management，目标机侧是 rpm / dnf 一族，不是 apt。

具体开关和第 9 篇一起写进模板即可；这里先记住机制。

改 Logo / 闪屏 / 时区等：改原文件，还是改 conf？

第 9 篇会改 GRUB Logo、psplash、包管理器、时区、语言。每项都能「改通」，但改法只有两类。本篇先定原则——后面加 hello 也按同一原则：

不要改 poky 里的上游原文件；把改动写进 conf 和自己的 layer。

方案 A：改上游原文件（能通，不推荐）

直接在 poky 源码树里改，例如：

想改什么	典型会去动的原文件（示意，以本机为准）
GRUB Logo	`meta/recipes-bsp/grub/` 下的 cfg / 图片
psplash	`meta/recipes-core/psplash/` 下的默认 PNG
包管理器	`core-image-base.bb` 里加 `IMAGE_FEATURES`，或改 `meta-poky` 的 sample
时区	`tzdata` 菜谱里的默认 `DEFAULT_TIMEZONE`
语言	distro 的 `poky.conf` 里的 `IMAGE_LINGUAS`

第一次改确实最快：文件就在眼前，改完就能编。但 git pull 升级 poky 时这些改动会被覆盖或冲突；虚机 / 真机两套 build 也分不清「哪些是上游、哪些是我的」；第 12 篇无法把定制干净推进 GitHub。

方案 B：在 conf / `meta-demo` 里改（本系列采用）

能写成变量的，优先写进 local.conf（以及 TEMPLATECONF 模板）；必须换文件的（Logo、闪屏图），在自己的 layer 里用 .bbappend 覆盖——效果等同配置层定制，不是改原文件。

想改什么	方案 A（改原文件）	方案 B（conf / 自己的 layer）
GRUB Logo	改 poky 里 grub 菜谱与 cfg	`meta-demo` 的 `.bbappend` + 自己的 PNG
psplash	替换 poky 里默认 PNG	闪屏已由 `IMAGE_FEATURES += "splash"` 启用；换图用 bbappend
包管理器	改 `core-image-base.bb`	`local.conf` ：`PACKAGE_CLASSES` + `package-management`
时区	改 tzdata 菜谱默认值	`local.conf` ：`DEFAULT_TIMEZONE = "Asia/Shanghai"`
语言	改 `poky.conf`	`local.conf` ：`IMAGE_LINGUAS`、`GLIBC_GENERATE_LOCALES`

第 9 篇对每一项都会对照这两种改法，并给出方案 B 的具体步骤。

在 conf 里改的好处

升级安全：把 poky 当只读上游；git pull 不会冲掉你的 Logo、时区、包管理开关。
边界清楚：meta/ 保持原样，meta-demo + 两份 TEMPLATECONF 才是「我的系统」。
双 MACHINE 共用：同一份 layer、同一套变量，虚机和真机一起生效，不必在两棵源码树里各改一遍。
可复现、可托管：模板进 Git（第 12 篇），别人用 TEMPLATECONF=... 就能得到同一套定制。
贴合 Yocto 的设计：时区、语言、包格式本来就是给 conf 准备的旋钮；硬改 .bb 等于绕开变量系统，以后更难排查「到底谁覆盖了谁」。

后面加 hello，也走方案 B：自己写 recipe，再用 IMAGE_INSTALL:append 装进镜像——不要在 core-image-base.bb 里塞一行 hello。

添加 hello：从 C 源码到 Yocto「菜谱」

只改 IMAGE_INSTALL 还不够，因为系统默认并不知道 hello 是什么。我们要写一个最简单的 recipe，并放进最小 layer meta-demo。这份自定义对两机型共用。

为什么要单独建 layer？

当然可以把文件随手塞进 poky 现有目录（那就是上一节的方案 A），但那不利于维护。单独建 meta-demo 的好处是：你清楚「哪些是上游原样，哪些是我加的」；也便于整层提交到 GitHub。

目标目录长什么样

本篇结束后，poky 下应大致是：

poky/meta-demo/  conf/layer.conf          # create-layer 生成  conf/templates/    qemux86-64/      local.conf.sample      bblayers.conf.sample    genericx86-64/      local.conf.sample      bblayers.conf.sample  recipes-example/hello/    hello_1.0.bb    files/hello.c

脚手架与模板尽量用 bitbake-layers 生成；hello 源码与菜谱用命令写入。下面按顺序做。

用命令创建 meta-demo

bitbake-layers 必须先进入某个 build 环境。先起一个临时目录 build-bootstrap（只用它跑脚手架命令；正式长编译仍用后面的 build-qemux86-64 / build-genericx86-64）：

# 以下均在 WSL2 Ubuntu 中；假定已按第 7 篇克隆好 pokycd ~/yocto/pokysource oe-init-build-env build-bootstrap# 如果指向bitbake-layers报错，则需要安装下面的依赖sudo apt install chrpath diffstat gawk zstd# 当前目录已是 build-bootstrap/，layer 建在上一级 poky 下bitbake-layers create-layer ../meta-demobitbake-layers add-layer ../meta-demobitbake-layers show-layers

期望：show-layers 列表里出现 meta-demo。

create-layer 会自动生成 conf/layer.conf、示例 recipe、COPYING.MIT、README 等，不必手写整份 layer 骨架。打开核对即可：

# 仍在 build-bootstrap 环境中grep LAYERSERIES_COMPAT ../meta-demo/conf/layer.conf

应包含你的版本代号（本系列为 scarthgap）。若没有或写错，改成：

LAYERSERIES_COMPAT_meta-demo = "scarthgap"

layer.conf 里其余常见项（BBFILES、BBFILE_COLLECTIONS、优先级等）一般保持命令生成结果即可。

路径说明：source oe-init-build-env 之后 shell 在 build-*/ 里，所以对 layer 写 ../meta-demo；若你 cd 回了 ~/yocto/poky，路径则写成 meta-demo。

用命令放入 hello，去掉自带 example

脚手架默认带 recipes-example/example/。本 demo 换成 hello：

# 仍建议在已 source 的 build-bootstrap 终端中操作rm -rf ../meta-demo/recipes-example/examplemkdir -p ../meta-demo/recipes-example/hello/filescat > ../meta-demo/recipes-example/hello/files/hello.c << 'EOF'#include <stdio.h>int main(void){    puts("Hello from Yocto-built Linux");return 0;}EOFcat > ../meta-demo/recipes-example/hello/hello_1.0.bb << 'EOF'SUMMARY = "Minimal hello demo"LICENSE = "MIT"LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"SRC_URI = "file://hello.c"S = "${WORKDIR}"do_compile() {${CC}${CFLAGS}${LDFLAGS} \      hello.c -o hello}do_install() {    install -d ${D}${bindir}    install -m 0755 hello \${D}${bindir}/hello}EOF

hello.c 就是标准 C 小程序：打印一行字后退出。菜谱含义：

SRC_URI：源码来自同目录 files/hello.c；
do_compile：用目标编译器把 hello.c 编成可执行文件 hello；
do_install：把结果安装到目标根文件系统的 /usr/bin/hello；
许可证相关行是 Yocto 的常规要求；LIC_FILES_CHKSUM 必须写成同一行的 file://…;md5=…（中间用 ; 连接）。若把 md5= 换到下一行，BitBake 会把它当成另一个非法 URL。

文件名 hello_1.0.bb 里的 1.0 表示版本号；包名是 hello。

可选：立刻确认 BitBake 能看见 hello（仍在 build-bootstrap）：

bitbake -s | grep "^hello"

配置模板：两套 MACHINE 各一份

模板文件名必须以 .sample 结尾。oe-init-build-env 在首次创建 build 目录时，会把模板拷成 conf/local.conf 与 conf/bblayers.conf。

推荐做法：先在 build-bootstrap 里改好一份可用配置，再用 bitbake-layers save-build-conf导出成模板，避免整份手抄。

在 bootstrap 里写好虚机策略

编辑 conf/local.conf（相对当前 build-bootstrap/），找到或追加：

# 虚机：qemux86-64MACHINE ??= "qemux86-64"# 只给本系列镜像追加格式；不要写成全局 IMAGE_FSTYPES:append# （全局追加会渗进 core-image-minimal-initramfs，触发#  「INITRD_IMAGE_LIVE … cannot use … hddimg」解析错误）IMAGE_FSTYPES:pn-core-image-base:append = " \  wic hddimg tar.bz2"# 把 hello 装进镜像（虚机/真机共用）IMAGE_INSTALL:append = " hello"# 两机型共用下载与 sstate：TOPDIR 是当前 build-*/，# 指到 poky 下同一目录，编译 qemux86-64 后再编 genericx86-64# 时，共用模块不必重复下载、也不必从零再编DL_DIR ?= "${TOPDIR}/../downloads"SSTATE_DIR ?= "${TOPDIR}/../sstate-cache"# 中国区可选：用清华镜像加速常见上游下载PREMIRRORS:prepend = "\  git://.*/.* https://mirrors.tuna.tsinghua.edu.cn/git/yocto/ \n \  git://.*/.* https://mirrors.ustc.edu.cn/yocto/ \n \  https?://.*/.* https://mirrors.tuna.tsinghua.edu.cn/yocto/https/ \n \  https?://.*/.* https://mirrors.ustc.edu.cn/yocto/ \n \  ftp://.*/.* https://mirrors.tuna.tsinghua.edu.cn/yocto/ftp/ \n \"# 可选：按 CPU 核数调整（WSL2 勿超过可用内存）# BB_NUMBER_THREADS = "8"# PARALLEL_MAKE = "-j 8"

bblayers.conf 一般不必再手改：前面的 add-layer 已写入 meta-demo。官方默认还会启用 meta、meta-poky、meta-yocto-bsp；qemux86-64 与 genericx86-64 都来自这些基础层，本 demo 不强制引入 meta-intel。

用命令导出两套模板

# 仍在 build-bootstrap 环境中bitbake-layers save-build-conf ../meta-demo qemux86-64# 改成真机 MACHINE 后再导出第二份# （可用编辑器改 conf/local.conf，或：）sed -i 's/^MACHINE ??= "qemux86-64"/MACHINE ??= "genericx86-64"/' conf/local.confbitbake-layers save-build-conf ../meta-demo genericx86-64

生成结果：

meta-demo/conf/templates/qemux86-64/  local.conf.sample  bblayers.conf.samplemeta-demo/conf/templates/genericx86-64/  local.conf.sample  bblayers.conf.sample

save-build-conf 会把本机绝对路径换成 ##OEROOT## 一类占位符，初始化时再还原——这正是模板可提交 Git、可在别人机器复用的关键。

快速核对：

grep 'MACHINE' ../meta-demo/conf/templates/*/local.conf.samplegrep -E 'DL_DIR|SSTATE_DIR' ../meta-demo/conf/templates/*/local.conf.samplegrep 'meta-demo' ../meta-demo/conf/templates/*/bblayers.conf.sample

期望：虚机模板为 qemux86-64，真机为 genericx86-64；两份模板的 DL_DIR / SSTATE_DIR 都指向 ${TOPDIR}/../downloads 与 ${TOPDIR}/../sstate-cache；两份 bblayers 都包含 meta-demo。

IMAGE_FSTYPES 对真机路径很重要：

格式	用途
wic / hddimg	写 U 盘
tar.bz2	双系统时把 rootfs 铺到硬盘分区

逐项用白话解释

配置项	白话
`MACHINE ??= "…"`	告诉 Yocto：这套系统是给 QEMU 虚机，还是给通用真机 PC
`IMAGE_FSTYPES:pn-core-image-base:append = ...`	只给 `core-image-base` 追加产物格式。`:pn-…` 是「仅作用于该配方」；若写成全局 `:append`，`hddimg`/`live`/`iso` 会渗进 initramfs 镜像并导致解析失败
`IMAGE_INSTALL:append = " hello"`	往最终 rootfs 里多装 hello。包必须由 recipe 提供。虚机与真机共用这一行
`DL_DIR` / `SSTATE_DIR`	下载缓存与共享状态缓存。默认各自落在 `build-*/` 里会重复干活；两套模板都指到 `poky/downloads` 与 `poky/sstate-cache` 后，先编虚机再编真机时，共用模块可直接复用。内核、机器相关打包仍会按 MACHINE 分开做，这很正常
`PREMIRRORS:prepend = ...` （中国区）	构建时大量时间花在下载源码包。把常见上游优先导向清华 TUNA，国内通常更快；未命中再回退原址
并行度变量	多开任务可能更快，也可能更吃内存；WSL2 下内存紧张时宁可保守

镜像名字 core-image-base 不必在 local.conf 里强制指定——第 10 篇执行 bitbake core-image-base 时再选定即可。

备选：若你更想手改 sample，也可 mkdir -p 模板目录，再从 meta-poky/conf/templates/default/ 复制 *.sample 后编辑；本系列优先 save-build-conf，少抄文件、少漏 add-layer。

用 TEMPLATECONF 初始化两个正式 build 目录

脚手架完成。下面用模板创建正式双机型目录（与 build-bootstrap 分开）：

cd ~/yocto/poky# 虚机构建目录（首次会从模板生成 conf）TEMPLATECONF=meta-demo/conf/templates/qemux86-64 \source oe-init-build-env build-qemux86-64# 另开终端，或 cd 回 poky 后再初始化真机目录cd ~/yocto/pokyTEMPLATECONF=meta-demo/conf/templates/genericx86-64 \source oe-init-build-env build-genericx86-64

build-bootstrap 完成使命后可删（可选），避免和正式目录搞混：

# 确认不再需要脚手架时再执行# rm -rf ~/yocto/poky/build-bootstrap

要点：

TEMPLATECONF 指向模板所在目录（里面有 *.sample），不是某个 sample 文件本身；
路径相对当前 poky 根目录即可；
只有首次创建该 build 目录时才会从模板拷贝；若目录已存在，改模板不会自动覆盖已有 conf/——那时请直接改 build-*/conf/，或删掉空 build 目录后重建（勿误删已有长编译产物，除非你有意为之）；
之后日常进入环境，不必再写 TEMPLATECONF：

cd ~/yocto/pokysource oe-init-build-env build-qemux86-64# 或source oe-init-build-env build-genericx86-64

执行后，终端当前目录通常变成对应的 build-*/。文中说的 conf/local.conf、conf/bblayers.conf 都相对于当前这个 build 目录。

第 9 篇若继续改 local.conf：虚机 / 真机两边都要改时，优先改两份 *.sample 模板（便于 Git），并同步到已有 build-*/conf/local.conf；或只改已初始化的两份 local.conf。

先校验，再开长构建

完整镜像编译很久，所以先用轻量命令确认配置被识别。以虚机目录为例：

cd ~/yocto/pokysource oe-init-build-env build-qemux86-64bitbake -e | grep "^MACHINE="bitbake -s | grep "^hello"

期望：MACHINE="qemux86-64"，且能列出 hello 包。

再校验真机目录：

cd ~/yocto/pokysource oe-init-build-env build-genericx86-64bitbake -e | grep "^MACHINE="bitbake -s | grep "^hello"

期望：MACHINE="genericx86-64"，同样能列出 hello。

如果找不到 hello：

检查对应 bblayers.conf 是否包含 meta-demo；
检查 recipe 文件名、目录是否按上文放置；
重新 source oe-init-build-env build-… 后再试。

如果报 INITRD_IMAGE_LIVE … cannot use … hddimg：

多半是写了全局 IMAGE_FSTYPES:append = " … hddimg …"；
改成 IMAGE_FSTYPES:pn-core-image-base:append = " wic hddimg tar.bz2"（正式 build-*/conf/local.conf 与两份 *.sample 都改）；
再跑 bitbake -s。

可选：只编译 hello 包，进一步验证菜谱本身：

bitbake hello

本篇小结

到本篇结束，你应该已经完成：

弄清默认镜像：内核经 MACHINE + virtual/kernel 进启动分区，不靠在 core-image-base.bb 里点名；apt 默认不在镜像里，要靠 conf 里的 PACKAGE_CLASSES + package-management；
定下定制原则：改 GRUB Logo、psplash、包管理器、时区、语言时，走 conf / meta-demo，不改 poky 原文件；
理解「一 MACHINE 一 build 目录」：build-qemux86-64 与 build-genericx86-64；
用 bitbake-layers create-layer / add-layer 建好 meta-demo，用命令写入 hello；
用 save-build-conf 导出两套 TEMPLATECONF（含共用的 DL_DIR / SSTATE_DIR），再用 TEMPLATECONF=… 分别初始化正式 build；
真机模板保留可写 U 盘 / 铺硬盘的产物格式；
用 bitbake -e / bitbake -s 在两个正式目录里都做了校验。

下一篇按「方案 B」把启动界面、内核版本、Bootloader Logo、时区语言、裁剪与包管理写进 conf / bbappend；配置如何用 Git 托管见第 12 篇。

系列文章列表：

从零构建 Linux 系统

从零构建 Linux｜01 启动流程总览

从零构建 Linux｜02 Bootloader

从零构建 Linux｜03 内核启动

从零构建 Linux｜04 Rootfs、init 与服务

从零构建 Linux｜05 包管理

从零构建 Linux｜06 Yocto 是什么

从零构建 Linux｜07 使用 Yocto

本文来自网友投稿或网络内容，如有侵犯您的权益请联系我们删除，联系邮箱：wyl860211@qq.com 。

配置模板：两套 MACHINE 各一份

在 bootstrap 里写好虚机策略

用命令导出两套模板

逐项用白话解释

用 TEMPLATECONF 初始化两个正式 build 目录

先校验，再开长构建

本篇小结

系列文章列表：

从零构建 Linux|08 配置自定义 Linux

为什么不用「一个 build 来回改 MACHINE」

先对比：两个 MACHINE 差在哪

动手加包之前：内核和 apt 是怎么进 `core-image-base` 的

内核：MACHINE → 虚拟提供者 → 镜像组装

apt：构建时打包 ≠ 目标机带 apt

改 Logo / 闪屏 / 时区等：改原文件，还是改 conf？

方案 A：改上游原文件（能通，不推荐）

方案 B：在 conf / `meta-demo` 里改（本系列采用）

在 conf 里改的好处

添加 hello：从 C 源码到 Yocto「菜谱」

为什么要单独建 layer？

目标目录长什么样

用命令创建 meta-demo

用命令放入 hello，去掉自带 example

最新文章

热门文章

随机文章

从零构建 Linux|08 配置自定义 Linux

为什么不用「一个 build 来回改 MACHINE」

先对比：两个 MACHINE 差在哪

动手加包之前：内核和 apt 是怎么进 core-image-base 的

内核：MACHINE → 虚拟提供者 → 镜像组装

apt：构建时打包 ≠ 目标机带 apt

改 Logo / 闪屏 / 时区等：改原文件，还是改 conf？

方案 A：改上游原文件（能通，不推荐）

方案 B：在 conf / meta-demo 里改（本系列采用）

在 conf 里改的好处

添加 hello：从 C 源码到 Yocto「菜谱」

为什么要单独建 layer？

目标目录长什么样

用命令创建 meta-demo

用命令放入 hello，去掉自带 example

配置模板：两套 MACHINE 各一份

在 bootstrap 里写好虚机策略

用命令导出两套模板

逐项用白话解释

用 TEMPLATECONF 初始化两个正式 build 目录

先校验，再开长构建

本篇小结

系列文章列表：

PrismLinux 2026.08.15 发布!

Linux 7.2 发布:迈向苹果 M3 支持,内核调度与驱动…

最新文章

热门文章

随机文章

动手加包之前：内核和 apt 是怎么进 `core-image-base` 的

方案 B：在 conf / `meta-demo` 里改（本系列采用）