大家好，今天我把系统装进了GitHub里面的公开仓库。
啊，没错，是公开的，说明了什么？
说明了只要有网络，全世界都能开来用。
那我是怎么做到的呢？这里我就想把我的实验心得分享给大家。

---

背景

这是这么做到的，先说明一下，这个实验来源于我的一个想法：

既然 GitHub 能托管文件，那我能不能把整个操作系统也放上去？

---

一.我要用到的技术和系统

要实现这个目标，我用到了这些东西：

1. iPXE——网络引导固件

iPXE引导界面

iPXE 是一种能从 HTTP 下载文件并引导系统的引导程序。它能在裸机上运行，支持：

• DHCP 获取 IP
• HTTP/HTTPS 下载文件

（自带的iPXE源文件只支持HTTP，如果你要用到HTTPS协议需要下载源码，重新编译封装）

• 直接引导 Linux 内核、Windows PE、ISO 镜像

有没有这么一种可能，它就像一个“迷你操作系统”（不知道能不能这么说），在 Windows/Linux 启动之前帮你从网上下载文件并启动系统。

2. GitHub Raw——文件直链服务

每个 GitHub 仓库里的文件，都有一个对应的 Raw 链接，格式是：

https://raw.githubusercontent.com/用户名/仓库名/分支名/文件路径

这个链接直接返回文件的原始二进制内容，没有任何网页包裹。这意味着 iPXE 可以直接通过 HTTP/HTTPS 下载这个文件。

GitHub的文件直链服务

3. 我实验了很久，结果尝试这个系统TinyCore Linux——恰好成功了，就很…你们懂吗…

经常用GitHub传文件的朋友都知道，GitHub 有着单文件 100MB 的限制，绝大多数现代操作系统都超过了100MB。

所以我就使用了 TinyCore Linux （其实我是后面才用的，给大家看看这些启动文件的大小）：

• 内核 vmlinuz：约 5MB
• 根文件系统 core.gz：约 15MB
• 加起来不到 20MB

而且它启动后直接运行在内存中，不需要硬盘。但这唯一的缺点是：你存的文件重启就没了。

（注意一下标题：“公开系统”，不是“共享系统”）

---

二、介绍环境

电脑	系统	作用
A电脑（构建机）	Win11（外加个Linux虚拟机）	准备好文件，负责上传到GitHub
B电脑（自己家的测试机）	Win7（其实只是用到主板的U盘内的iPXE启动而已）	测试iPXE网络引导是否正常运行
C电脑（朋友家的测试机）	Win7（其实也只是用到主板的U盘内的iPXE启动而已）	测试公开性（能不能跨网络连接）

---

二、实验实现原理和要注意的事情

整个方案的链条是：

GitHub 存储文件 → HTTPS 分发 → iPXE 下载 → 启动系统

原理不复杂，但有几个 GitHub 的限制必须得提前了解。

GitHub 文件大小限制

GitHub 免费仓库对文件大小有两个限制：

• 通过网页上传：25MB
• 通过 git push 上传：100MB

所以说我准备的系统镜像必须小于 100MB，这没啥好说的。

可能有人会问，Git LFS 可以存大文件啊，我为什么不用 Git LFS？

第一点-因为 Git LFS 有流量配额：

• 免费版：每月 1GB 存储 + 1GB 带宽

下载镜像几次，配额就用完了。那不好意思，你要等下个月才能开了。

而且 iPXE 无法直接处理 Git LFS 的指针文件，必须额外调用 API。

所以我觉得 Git LFS 不适合做公开的分发载体。

这说明了什么？

说明我只能找 100MB 以下的系统镜像。

小于100MB的Windows系统镜像特别的难找 （最小精简版也要 1-2GB），Windows这边我这里打算用NativeWin11（只有Native内核版本的Win11哦，才25MB）

只有内核模式的Win11，开机是这样的（只有这种界面）

Linux 发行版里也只有 Alpine、TinyCore、Puppy 这类极简系统符合要求。我选了 TinyCore，因为它最“标准”，我说的是：这个系统是内核+initrd 分离，iPXE 可以直接加载。

---

四、开始实验（我做了什么）

先给大家看看，这是我自己的个人主页

创建一个公开仓库

这个仓库名我就写成iPXE_NativeWin11吧（我打算先走Windows路线，试一下Native版本的Win11能不能行，我这里先用着这个名字）

创建仓库

好，这里一个公开仓库就这样水灵灵地建好了。

准备引导文件（wimboot 和 boot.wim）

一开始我走的是 Windows 方向。我手头有一个 30MB 的 boot.wim（Windows 11 精简版内核），打算用 wimboot 引导它。

wimboot 是 iPXE 官方提供的工具，专门用来引导 Windows 的 .wim 镜像。

我把 boot.wim 和 wimboot 一起上传到 GitHub 公开仓库，然后编写了一个简单的 boot.ipxe 脚本：

#!ipxe
dhcp
kernel https://raw.githubusercontent.com/.../wimboot
initrd https://raw.githubusercontent.com/.../boot.wim boot.wim
boot

然后通过Git上传了文件。

上传文件

之后编译 iPXE

官方预编译的 iPXE 默认不支持 HTTPS。所以这里我只能自己编译（所以我开了一个Linux虚拟机）。

编译过程中踩了两个大坑：

1. 需要修改 src/config/general.h，启用 DOWNLOAD_PROTO_HTTPS
2. BIOS 模式下有一段代码会强制 #undef DOWNLOAD_PROTO_HTTPS，必须手动注释掉

还要指定证书链（TRUST 参数），否则 HTTPS 连接失败。

我这里折腾了整整一下午，终于编译出一个带 HTTPS 支持的 ipxe.iso。

刻入启动盘

用 Rufus 把 ipxe.iso 写入 U 盘，选择 DD 模式（否则无法启动）。

第一次失败：HTTPS 地址解析没加载成功

插上 U 盘启动，iPXE 执行 chain 命令后提示：

Could not start download: Operation not supported (https://ipxe.org/3c892883)

检查后发现，我虽然编译了 HTTPS 支持，但 boot.ipxe 里用的是 https://，而 iPXE 的 Features 列表里没有 HTTPS。

原来是编译时 general.h 里的 PLATFORM_pcbios 那段 #undef 没注释干净。重新编译后，Features 里出现了 HTTPS，问题解决。

第二次失败：缺少 bootmgr

HTTPS 通了，但 wimboot 报错：

我的 boot.wim 是极度精简版，内部没有 bootmgr 文件。wimboot 需要 \Boot\BCD 和根目录下的 bootmgr。

我从官方 Windows ISO 里提取了 bootmgr、BCD、boot.sdi，塞进 boot.wim 的对应目录，重新上传。

第三次失败：BCD 怎么调都不对

补了 bootmgr 后，Windows Boot Manager 出来了，但报错了。

我试了：

• 从官方 ISO 复制 BCD
• 用 bcdboot 重建（但在挂载目录下执行失败）
• 手动用 bcdedit 修改路径
• 调整 path 为 \Windows\System32\winload.exe

换了七八个版本的 BCD，错误代码从 0xc000000f 变成 0xc0000428，再变成 0xc000000e……始终调不好。

第四次失败：Bad CPIO magic

换用 wimboot 2.7.5 版本，重新导出未压缩的 WIM，结果报：

Bad CPIO magic
FATAL: could not extract initrd files

搜索了一圈，社区里说这是 BIOS 模式下 wimboot 对 WIM 内部结构的兼容性问题。有人建议用 --pe 参数，有人建议换旧版，但对我都没用。

第五次失败：sanboot 也挂了

我决定放弃 wimboot，改用 sanboot 直接引导 ISO。

我把 Windows PE 打包成 ISO，上传，然后：

sanboot https://.../winpe.iso

Loading files等了足足半小时

Loading files等了足足半小时，结果 Windows Boot Manager 又报错了：

后面查了资料才发现：

sanboot 在 Windows 内核加载后会丢失虚拟设备，导致 I/O 错误。

Windows方向我不打算继续折腾了，我这里换用Linux路线。

成功：转向 TinyCore Linux

我放弃了 Windows，转向 Linux。

下载 TinyCore 的 vmlinuz 和 core.gz，上传到 GitHub，编写 boot.ipxe：

#!ipxe
dhcp
kernel https://.../vmlinuz quiet
initrd https://.../core.gz
boot

然后 iPXE 执行 chain，一次成功！

从开机到进入 Linux 命令行，不到 30 秒。

---

五、测试一下是否能公开

方案跑通了，但 GitHub 的 Raw 链接在公网上真的能用吗？会不会被限流？会不会出问题？

为了验证，我带着启动 U 盘跑到朋友家，借用他的电脑（不同网络、不同地区）进行测试。

结果：顺利进入 TinyCore Linux！

从插入 U 盘到进入命令行，全程约 25 秒。GitHub 的全球 CDN 节点发挥了作用，下载速度比我想象的快。

GitHub里面的系统能进，没有问题。毕竟这是CLI界面，我尝试一下安装GUI组件，看一下能不能行。

下载好了，startx试一下。

系统能进，组件能装，只要保证有外网，能读取TinyCore Linux的源就行了。

这说明这个方案确实可以公开使用，任何能联网的电脑都能通过网络启动这个系统。

---

六、总结

数据对比

方案	文件大小	启动时间	成功率
Windows PE + wimboot	30-100MB	2-5分钟	❌ 失败
ISO + sanboot	200MB+	3-10分钟	❌ 失败
TinyCore + kernel/initrd	<20MB	20-30秒	✅ 成功

这说明了什么？（经验教训）

1. Windows 不适合这个方案——wimboot 对 WIM 格式要求有点苛刻，BCD 配置有点地狱，BIOS 模式下兼容性极差（也有可能是我技术不行）。
2. Linux 是王道——kernel + initrd 是标准做法，iPXE 原生支持，几乎不出错。
3. 编译 iPXE 时要小心——默认不带 HTTPS，BIOS 下还有额外的 #undef，要仔细检查。
4. 必须是要通过DD 模式写入 U 盘——否则启动不了。
5. GitHub 的 Raw 链接确实能当 CDN 用——只要文件够小，不滥用，完全可行。

最终成果

• 系统镜像：< 20MB
• 启动时间：20-30 秒
• 客户端要求：任何有网口、支持 U 盘启动的电脑
• 服务端成本：0 元（GitHub 免费）
• 可访问范围：全球（只要有网络）

---

这个项目的意义不在于“把系统装进 GitHub”这个行为本身，而在于它打通了一条链路：

GitHub 存储 → HTTPS 分发 → iPXE 网络引导 → 内存运行

技术的魅力就在于，当你把几个看似不相关的工具组合在一起时，会产生意想不到的化学反应。

（这文笔有点奇怪，但就这样写了）

如果你也感兴趣，可以到我的 GitHub 仓库看看：

GitHub-@GaltonLai（iPXE_NativeWin11项目）

感谢大家看到这里，如果你对我的GitHub项目感兴趣，欢迎 Star、Fork、提 Issue！

（写于2026.7.20）