github 项目地址如下，欢迎 star：
https://github.com/leitbogioro/Tools
图库来自 imgur.com ，需要挂梯子全局访问才能正常显示。
这个帖子放在主贴 https://91ai.net/thread-1159839-1-1.html（Linux一键重装支持Debian 12，Ubuntu 22.04，史上最强）中，篇幅实在过于冗长，对仅需要使用 Linux 一键重装脚本的朋友来说会带来很大困惑，也有可能会忽略掉默认密码：LeitboGio0ro 等关键信息，让所以我把它单独开辟出来，供有兴趣的人自行研究。
20230618 更新：
论原生启动网络启动文件，按自动应答制定的策略安装，和启动中介系统 dd 安装的区别，就和宝塔面板里安装 Nginx PHP 等“编译安装”和“快速安装”的区别差不多，前者是原生安装，后者是将打包好的系统直接 dd 解压到目标硬盘，在有可能的情况下，我还是坚持使用“编译安装”的思路，因为这种安装方式会经历安装程序对系统环境进行一个详尽检测的过程，它会对目标机器的硬件是否满足运行要求，展开适合目标机器硬件的二进制代码/驱动进行检查和展开。相比于“一个文件包”走天下的 dd 式安装，肯定是优势更大的。
dd 安装的优势仅仅是“能在 1GB 机器上安装 CentOS”，so？红帽官方显然为不同版本的 Redhat 制定了安装的内存要求，这是官方在经过大量机器的适配和反馈后，获得的经验，你再懂不可能有人家懂，内存方面，红帽 7 要求至少 1.5GB，红帽 8 要求至少 2.5GB，红帽 9 改善了很多，降到了 2GB 就能安装，这还是官方明确规定推荐内存大小 3GB，我去掉了启动内核时的内存检查，经过实验获得的实际最小内存要求，硬要强行突破安装程序自己的内存检查流程，在不适合的配置上强行 dd 安装，我觉得这种做法带来的后果和风险是很大的，我见过太多建立机器时选择红帽 8+ 模板的 1GB 机器，用 dnf install 常用软件面临“process killed”的例子了。
所以：内存不够就不要强装，这个道理很简单，人人都应该懂。
通过以上论述，我们已经知道了安装 Ubuntu 不得不用 dd 方式的原因，而且由于对使用 Ubuntu 有需求的朋友多，所以再麻烦也要把这个难题解决，而且由官方制作的 dd 包，肯定比我们个人开发者自己制作的兼容性要更好，且更新及时，有问题能够及时修复，我服务端已实现脚本自动打包，无需我本人亲自参与，除非甲骨文把我号删了，如果脚本所有支持安装的目标系统都采用 dd，那我需要面临的后果就是：
兼容性大大减弱；自己要定期制作、适配、存储一大批 dd 包；安装镜像源不再提供自选，只能连接有限的几个（甚至只有一个）目标服务器，一旦我本人无力维护 2 步骤中的制作，或服务器 down 掉，脚本相关功能也就整个废掉；全世界各地镜像源的维护者们一定比我更专业、财力更高、服务也更稳定，而且能选择就近（服务器所在地）源，大大提高安装速度，我很清楚我自己能力的局限和边界，能采用镜像源原生安装，我就绝不自己提供相关 dd 镜像包服务。
很典型的案例就是 cxt，他声称制作了一大堆 dd 包，自己为维护这些 dd 包，要用百余个 GB 云空间来存储这些 dd 包，而且每当如果有新的 Linux 发新版发布，未来可能出现新的主板固件（BIOS UEFI 之外）等，自己又要制作、上传新的系统包，让服务器的存储、流量压力日渐庞大，这种工作我的评价是：只有苦劳，没有功劳。把自己累死，也不一定获得什么好的成效，而且他那个网站，每十分钟甚至九分钟的时候，不是处于连接速度过慢，就是宕机的情况，github 上只有主程序一个代码空壳，所谓的“全球 CDN 加速”，仅仅是下载主程序时可以选一个更快的节点，一旦他维护的存储 dd 镜像的服务器炸了，整个脚本功能就废掉，号称支持再多，最后也只会变成 0，这种把鸡蛋都装在一个篮子里的思维无疑是值得商榷的。
前段时间有个坛友给我发了个私信，他说 Ubuntu 在今年（2023）2 月份的时候，鼓捣出来一个新型 netboot 方式，看看能不能重启以前加载最小内核，启动网络安装那一套。
https://lists.ubuntu.com/archives/ubuntu-devel/2023-February/042490.html
https://github.com/canonical/mini-iso-tools
我经过确认，相关项目已经更新到 Ubuntu 23.04 (Lunar Lobster) 分支：
https://releases.ubuntu.com/lunar/
我知道你很激动，但你先不要激动，因为我在激动完，测试了一下这个“netboot”文件后，对其评价是“依托答辩”，理由如下：
仅支持 amd64，不见 arm64 踪影，为保持不同架构 CPU 安装过程的一致性，没有经过全架构适配的 netboot 模式我是不会采取选择的； https://releases.ubuntu.com/lunar/netboot/
我下载了该页面中的 initrd 和 linux 内核，并尝试写入 grub 引导菜单启动，但效果还是极其差强人意，它竟然要把整个安装的 iso 镜像加载到内存里，然后完成后续安装，拜托 Ubuntu 22.04 的 iso 镜像尺寸有 1.83G 诶，要有容纳这么大一个文件的内存空间，你这么搞机器没 4GB 都不够装的，得有多少小内存机器被拒之门外。
grub 引导选项，写在文件 /etc/grub.d/40_custom 中，重启前记得 grub-reboot "Install Ubuntu" 让这个新菜单启动：
启动后机器会疯狂地寻找并读取光盘设备内容 sr0（实验机型 Racknerd 的 sr0 光盘是空的，且 web 面板无法选择挂载远程或自己上传的 iso 镜像，只是系统里多了这么一个虚拟设备），然后尝试很久后，再弹出对话框确认是否配置网络、镜像源链接等：
找不到本地光盘，开始跟你对话是否加载网络 iso，经过一次次回车（dhcp 还好办，如果是静态配置 IPv4/IPv6 网络，还得手输 IP 掩码 网关等静态网络参数），好家伙，开始往内存里写 iso 了，这得有多大内存才够你造的，即使我这台实验机型内存 4GB，也不能完整跑完 iso 镜像加载到内存中的流程，加载到 1422M 左右就提示“No space left on device”，低于这个内存量的机器更不可能不够它写，照这么看，得 8GB 内存才能顺利完成 iso 加载到内存里的步骤，啥人家啊，能用得起 8GB 内存的大鸡鸡，除了白瓢的甲骨文 ARM，后面的实验流程就不继续了，反正给人的感觉就是恶心他妈给恶心开门，恶心到家了：
配置这种 netboot 内核启动方式可参考的文档和经验为 0，连 4GB 内存都不够加载就够要命的了，要是再出什么其他问题，根本没有办法调试。Ubuntu 开发者们的脑子里有个弯还是没绕过来，他们还是坚持认为，所有人都应该下载一个硕大的 iso 文件，然后拥有写入 U 盘或光盘或内存，插到电脑上安装的条件，或者是像云服务商那样，可以随时给机器 dd，完全不考虑用一个精简内核启动，然后完成读取 cloud init 配置文件完成后续的安装过程。
所以综合以上论述，我还是决定采用服务端制作从官方同步的 Ubuntu cloud images，客户机采用从 AlpineLinux 中介系统启动 dd，重启后机器根据 dd 时埋入的 cloud init 配置完成正确的配置流程，是能够在“减少我个人维护 dd 包制作繁琐程度”和“原生初始化系统”之间，取得一个良好平衡的方案。
寻找并确定了当前最适合的解决方案后，Ubuntu netboot 更新与否我就不太关心了，如果你在未来哪天，发现 Ubuntu netboot 已经不再采用以上蛋疼的方式安装系统，回到 Debian 那种最小化内核启动，读取 cloud init 就能完成安装的方式，请立即联系我，我也会在后续迅速跟进并更新相关安装方案。
