Chiphell - 分享与交流用户体验

标题: iPXE iSCSI无盘安装及引导 Win11／10 连载(上) — WDS篇 [打印本页]

作者: imyz 时间: 2024-3-12 13:50
标题: iPXE iSCSI无盘安装及引导 Win11／10 连载(上) — WDS篇
本帖最后由 imyz 于 2024-3-19 11:10 编辑

** 前言

   开篇先交待下背景。正如我 2022 年 10 月 NUC9 iSCSI无盘工作站/服务器札记 — PXE安装及引导 Win11 成功帖中所说，通过 iSCSI 无盘安装及引导 Win11/10 是基于主板或网卡自带 iSCSI 配置功能为前提的，显然绝大多数的电脑不具备该功能，即使是商务电脑也鲜有，VMware 想都不敢想，门槛确实不低，况且 Intel 早已官宣放弃 NUC，长远来讲我也应该尽早考虑更普适的无盘方案，这是其一；但最关键的应属这其二，假如不是最近正纠结是否入手带 780M 核显的零刻 SER7 准系统的话，“其一”的理由还不足以让我有动力写这篇连载，而真正促使我动笔的原因是不久前刚咨询过零刻官方，答复说他家的都不自带 iSCSI 功能，为了防止自己哪天突然决定下单，同时保持 iSCSI 无盘基本方针不动摇，iPXE 俨然已迫在眉睫。假如认真读过我 NUC9 iSCSI 帖的看官，应该注意到了那时我也研究过一阵子 iPXE，幸亏当时没成功，否则就不会有那篇纯 M$ 环境的解决方案。在进入正题前，我照例会在教程中花大量的文字交待各项操作的前因后果。

   言归正传。这次的连载是作为 NUC9 iSCSI 帖的姊妹篇。（上）篇如题，除必须用到的 iPXE 外，全程基于与此前完全相同的纯 M$ 环境，还没看过前帖的若有必要还请先回头补补课。（下）篇这里提前剧透下：将彻底抛开 M$ 环境而改用 Linux + wimboot，更熟悉或更偏好 Linux 环境的看官可跳过（上），直接等（下）。

   针对我所使用的系统环境，这次先重点讲下客户端。我是用 VMware 虚拟机模拟实体机，原因是目前手上仅存一台 NUC9 客户机可用，也就是 2022 年帖子中的同一台，若用它作客户机，我就再没可随时调整服务器配置的机器，这是现实所迫；另一方面，假如虚拟机都能完成，那么实体机理论上应能如法炮制。可是在我实际操作中却出现了意外，iPXE Client 虚拟机虽然可以从 WDS/TFTP 中下载 ipxe.efi 并自举，但却始终无法正确获得 DHCP 策略中的关键配置，比如：next-server、filename 等，导致 iPXE 不能在启动时自动加载配置好的脚本，这意味着每次启动都不得不手工介入引导，让我这种有点技术洁癖的实在没法忍，找了很久的原因后，突然在 iPXE 引导后的 config 中找到问题，我 Windows DHCP 服务器的地址是明明是 .10 结尾，但 config 中却显示 dhcp-server 为我家庭网关 AirPort Time Capsule 的地址，显然是它“截胡”了 Windows DHCP，但 Apple 没有提供可以单独关闭 DHCP 的功能…… 想来想去，我决定在不改变现有硬件的前提下，临时新加一个 VLAN 并用虚拟机来模拟一个网关，先来看下整个环境大致的拓扑图：

(, 下载次数: 79)

   拓扑图右侧 VLAN 2 即是上述为避免 DHCP 被截胡而新建的，用来模拟“内网”，左侧的 VLAN 1 则是日常家庭网，用来模拟“公网”，正中间的 vRouter NAT 是一台 WinServer 2022 虚拟机，配置路由 NAT 来模拟一台普通不开启 DHCP 服务的家用路由器，分配两张虚拟网卡，其中一张 192.168.1.x/24 模拟公网 PPPoE，任由 AirPort 或 Windows DHCP 为它动态分配地址；而另一张 10.1.1.1/24 则是手工指定，用作 VLAN 2 段的网关；而 VLAN 2 段内的 DHCP + WDS 则同时部署在新建的一台 IP=10.1.1.10 的 WinServer 2022 上，当 vRouter 关机或停止 NAT 服务时 VLAN 1 与 VLAN 2 无法通讯。经这样调整后，位于 VLAN 2 中的 iPXE Client 终于可以正确地获取 10.1.1.10 下发的 DHCP 策略，iPXE 在自举完成后自动链式加载 DHCP 服务器指定的菜单脚本，不必再手工介入，基本达成了模拟的预期。有一点要提醒下，若有看官与我一样使用虚拟机的，建议勿将虚拟网卡配置为 E1000e，否则它在下载 boot.wim 到内存这个环节会慢得令人发中指，至少在我的环境中是这样，而改配置为 vmxnet3 就正常，也可能与我 ESXi 宿主机使用 AMD 平台有关吧，这里不深究。不过 vmxnet3 也有一个问题：WinPE 默认不提供 vmxnet3 的驱动，一旦进入 WinPE 环境后就会因失去网络连接而无法继续。解决方法有两个：
   A. 利用 WDS 的添加驱动功能直接将驱动集成至启动映像中；
   B. 根据我 NUC9 iSCSI 那帖从零开始定制启动映像；

(, 下载次数: 89)
(, 下载次数: 86)

   方法虽然有了，可上哪儿找驱动呢？要知道 VMware 官网并不直接提供 vmxnet3 的驱动，而是将它打包在 VMware Tools 中，所以解决办法是先用 VMware 虚拟机以“本地虚拟磁盘”方式安装完 Win11 后再安装 VMware Tools，所有的驱动会保存在 C:\Program Files\Common Files\VMware\Drivers\ 目录中，对于 iSCSI 安装来讲，仅须 vmxnet3 这个目录中的驱动即可。不想仅仅为了一个虚拟网卡的驱动再额外安装虚拟机的看官，我在教程结尾会附上下载以节省大·家·宝贵的时间。先来看下最终的成品吧：

(, 下载次数: 75)

   此处有必要再强调下“无盘”这个大前提，就是不采用包括 USB、CD-ROM 等在内的可引导介质，仅依靠网卡和网络完成操作系统安装和引导全过程。所以我的虚拟机除了 CPU、RAM 和虚拟网卡这些不可少的外，其余尽数删除，这样进入 WinPE 只能全程键盘操作，并且重启进入 Windows 后因为没有光驱也安装不了 VMware Tools；若是希望用鼠标操作的，则需要保留或添加 USB Controller，而各位自行操作时完全可以采用默认配置，我那样做只是为了给大家说明展示之用。值得注意的是：VMware 虚拟机的 Secure Boot 安全启动功能一定要禁用，否则 iPXE 在该虚拟机中无法工作。如图：

(, 下载次数: 77)
(, 下载次数: 89)
(, 下载次数: 76)

   已知 WDS 可以让一台电脑仅用网卡完成引导并进入 WinPE，其流程是让 DHCP 服务器先指示客户机从指定的 TFTP 服务器中取得 wdsmgfw.efi 完成 BOOTP 自举，随后下载 boot.wim 完成 WinPE 启动，若主板或网卡本身支持 iSCSI（即提供 iBFT），那么经定制后的 WinPE 就能识别并自动加载 iSCSI 目标盘，这就是 2022 年帖子的理论基础。遗憾的是，wdsmgfw.efi 和 VMware 均不提供 iBFT，那么，如何在仅有一块网卡的情况下将 WDS 服务器中的 ipxe.efi 通过网络传给客户机来接手 UEFI/BIOS POST 后的 Bootstrap 自举？

   假如在不改变 WDS 原有配置的情况下，可能有人第一反应是将 wdsmgfw.efi 改名或移到其它位置，并将 ipxe.efi 重命名以替换之。我试过，通过 iPXE 的手工命令或写脚本自动加载也是可行的，不过这样就改变了 WDS 原生的功能，并且有可能在 Windows Update 会予以“修复”，得不偿失，所以最理想的方式是不动 WDS 而让 iPXE 前置于它。由此，上一个问题就被转化成了：如何让 DHCP 服务器在收到客户机请求后首先指示客户机从指定的 TFTP（WDS）中获取 ipxe.efi？一旦 ipxe.efi 自举完成，第二阶段的引导则可由 iPXE 根据需求来“定制” —— 这就是本篇的基本思路。接下来的教程将分以下两部分进行讲解或展示：
（一）针对 iPXE 行为的 DHCP 服务器配置；
（二）iPXE 定制化配置与脚本。

   为便于区分章节，请各看官移步 2 楼观看教程第（一）部分。在移步之前还有个准备工作不能少，请先从 iPXE 官网下载最新的引导文件，或者直接下载我附在教程结尾的亦可。（上）篇只涉及其中三几个引导文件，分别如下：
   1. ipxe.efi，适用于 UEFI x64 或 UEFI x86；
   2. undionly.kpxe，适用于 Legacy BIOS x64 & x86；
   3. snponly.efi，适用于 UEFI x64 或 UEFI x86，当 ipxe.efi 无法正常引导时使用。

   建议各位按我下图中所示将各个文件分别保存到相应的文件夹中，否则，习惯抄作业的小盆友可能会遇到文件不存在这类的错误而不知所措。我的 iPXE 文件夹位于 WDS 服务器默认的 C:\RemoteInstall\Boot\ 下：
(, 下载次数: 69)

   iPXE 文件夹下分别又创建了 UEFI 与 Legacy 子文件夹，其中 UEFI 中存 ipxe.efi 与 snponly.efi，Legacy 中存 undionly.kpxe，而其余的 *.ipxe 文件是自己创建的脚本文件（详见教程第（二）部分）。而那个无扩展名的 wimboot 在（下）篇中才会用到，包括那个 WinPE 文件夹，这里请直接忽略二者。

(, 下载次数: 69)
(, 下载次数: 79)

---------- 增补内容 - 2024/03/15 ----------
（上）发布后回想下，上面图示方式似乎是我考虑不周，完全是从我自己的角度考虑。为使各看官对这个 iPXE 文件夹目录结构能一目了然，在此用树形方式列出其结构：

iPXE
├─ UEFI
│ ├─ ipxe.efi
│ └─ snponly.efi
│
├─ Legacy
│ └─ undionly.kpxe
│
├─ menu.ipxe
└─ sanhook.ipxe

注：该目录结构仅包含此篇内容涉及到的文件，虽与图示存在差异，但不影响原文内容以及实际使用。
---------- 增补结束 ----------

   在结束简单而又简短的前言之前，请容我再多句嘴：虽然我不久前知道了楼层本身有分页功能，但鉴于 CHH 似乎有一个不定期锁旧帖的惯例？？虽然我坛龄尚浅，但作为一名亲历者，为在将来的某天能方便快速地将帖保存为 pdf 以免遭不幸，我还是继续沿用分楼层的方式。望各位看官多包涵！

作者: imyz 时间: 2024-3-12 13:50
标题: （一）DHCP 服务器配置
本帖最后由 imyz 于 2024-3-13 14:12 编辑

   假如有看官曾了解过 iPXE 的话，应该知道 iPXE 在自举完成后，必须借助 DHCP 的指令将引导权交给下一个引导，即：Chainload 链式引导，否则会进入 Infinite Loop 自身无限循环。另一方面，WDS 实现 WinPE 引导的过程，实际上也须借助 DHCP 服务器的指令，区别在于，WDS 的模式是不论客户机请求几次都只下发一个固定的启动文件，如：wdsmgfw.efi。显然 NUC9 iSCSI 帖中 DHCP 服务器原有的配置已不再适用于 iPXE 的 Chainload 特性，欲打破 iPXE 无限循环，DHCP 服务器必须具有能够提供客户机第二个启动文件的能力，对此，iPXE 官网给出了 M$ DHCP 服务器的基本配置方法：Using the Microsoft DHCP server，以及 Installing to an iSCSI target using WDS 等。

   既然官方已给出了配置方法，是不是说我这个教程存在的意义就不大了？结论当然是否定的，因为我最终并没有完全采用官方的配方，因为它不够灵活，比如：1.为网卡/客户机配置“Reservation保留”不适用于批量的场景；2.将 root-path 根路径写入 DHCP 中不便今后修改；3.完成安装后再次重启时如何快速跳过安装？4.若同时有 UEFI 和 Legacy BIOS 的客户机时，如何自动识别并给出正确的启动文件？…… 我这里并不是在批评 iPXE，毕竟它只是为了解释原理，在清楚了原理的情况下，如何最大限度地方便日常使用，就是我这篇教程的目的。作为与官方的对比，还是先来看看我的配置吧：

(, 下载次数: 60)
(, 下载次数: 78)

   熟悉 Windows Server 的应该一眼就看出，核心思想就是通过配置“策略”来确定“服务器选项”。Linux 大佬们看到这里心里必定是会心一笑，毕竟像 isc-dhcp-server 和 dnsmasq 都能够很方便地配出我图上要达到的效果。假如还有同时熟悉 iPXE 的大佬，相信看到这里就已经没必要再继续往下看了。所以，接下来的内容其实是为像我当初一样初出茅庐的看官们准备的。内容虽然并不复杂，但还是请抓牢扶稳，准备开车…噢，不…开始：

   1. 在开始建策略前请再仔细看上图策略配置中的“处理顺序”一列，意思是策略是有优先顺序的，当然它的顺序也是可以通过“上/下移”来调整的。所以，无论你的策略起初是以什么顺序创建的，都必须必确保 Chainload 那条的处理顺序高于所有的 Boot 策略！
   2. 现在按 iPXE 官网的配置方法添加一个“User Class 用户类”。打开 DHCP 管理器，展开并右键点击 IPv4 -> 定义用户类 -> 添加，然后按提示操作直至如图所示后点确定。提示：ASCII 那里是可以鼠标点后键盘录入的，不必去录二进制值；大小写得严格区分，不能错。

(, 下载次数: 83)
(, 下载次数: 72)

   3. 随后再添加“Vendor Class 供应商类”，主要用来识别 UEFI、Legacy BIOS，以及 x86、x64 等客户机类型。这条不是我的原创，原帖门牌号：Installing and Configuring Windows Deployment Services for PXE Booting with Windows Server。添加方法基本同用户类，区分大小写、不必去录二进制。

(, 下载次数: 75)
(, 下载次数: 73)
(, 下载次数: 82)

   4. 接着就是教程（一）部分中最核心的步骤，对不熟悉的人而言也是容易出错的地方。请先仔细看下图中共有 4 条策略，从名称上看可知分为 Boot 和 Chainload 两类，分别指启动和链式加载。若不懂什么意思的也不必现在一定要弄明白，先如下图鼠标左键选中左侧栏中的“策略”，随后右键点击 -> 新建策略(P)：

(, 下载次数: 76)

   紧接着按上图所示为新策略命名，或者按自己好记的名称命名并点击“下一步”后即进入下图所示的“为策略配置条件”，图中是我 iPXE Boot 策略的配置，须通过点“添加”按钮手工添加。

(, 下载次数: 73)

   点上图中“添加”按钮后即弹出下图的条件配置页。点击“值”的下拉框将会看到之前手工定义的供应商类别，请务必先确保勾选“附加通配符(*)(A)”这项后再点添加按钮！确认无误后再点确定。

   注：Chainload 策略的配置与 Boot 的区别是将下图中的“条件(C)”改为“用户类”，并且将“值(V)”改为“iPXE”，不必附加任何通配符。

(, 下载次数: 72)

   当条件添加完成后，即可点“下一步”进入 “为策略配置设置”，实际上就是在配置“服务器选项”。此处的“供应商类(V)”如下图所示用默认的 DHCP Standard Options，随后翻动其下的列表并找到 066、067 两项，其中 066 即是指定 TFTP 服务器 ip 地址，本篇是讲用 WDS 作为 TFTP/BOOTP 服务器，所以就填 WDS 服务器的 ip；而 067 启动文件名则须根据上一步条件中所选的供应商类的值而不同，若选 (UEFI x64/x86) 则对应 ipxe.efi，而 (BIOS x64/x86) 则对应 undionly.kpxe。

   注：Chainload 策略 067 启动文件的字符串值(S)请填：Boot\iPXE\menu.ipxe。此外，若 iPXE 的文件是严格按照 1 楼所说存放的，那么这里可以照抄。否则请务必指定正确的路径；此外，虽然 WDS 配置是大小写不敏感的，但还是建议习惯上区分，因为 Linux/Unix 是大小写敏感的系统，区分大小写的适用性更好。

(, 下载次数: 67)

   5. 当确认所有配置无误后点下一步 -> 完成。反复操作直至与我给出的配置一致。
   6. 在配置 WDS 的过程中，若曾勾选过“配置 DHCP 选项以指示此服务器也是 PXE 服务器”，则 DHCP 服务器中可能会默认存在下图所示的 Option 060，请务必删除它，否则，它有可能使所有的策略均无效。下图中“策略名称”列中显示“无”的表示不是由策略创建的，这类选项如“006 DNS 服务器”则可根据各自实际情况决定其去留：

(, 下载次数: 80)

   7. 至此，M$ DHCP 服务器的所有配置已完成，但别急，还有最后一步，若你的 DHCP 服务器和我的一样是与 WDS 是在同一台机器上的，则请再确认一下 WDS 服务器中关于 DHCP 的配置是否如下图所示，若不是的，则请按图示修改并应用：

(, 下载次数: 74)

   否则，它有可能会与 DHCP 服务器形成冲突，要么就是 WDS 服务无法正常启动，要么造成 DHCP 无法绑定接口连接（UDP 67）而无法提供服务。正常情况下，右键点 DHCP 服务器 -> 添加/删除绑定，在 IPv4 卡中“连接和服务器绑定(C)”的 Checkbox 应如下图所示是勾选上的。否则，请仔细检查配置，或重启服务器。

(, 下载次数: 70)
(, 下载次数: 73)

   8. 昨天因发帖匆忙，最终还是忘记提醒各位一件也不知道算不算得上问题的事儿，就是建议大家将 DHCP 作用域(DHCP Scope) -> 属性(Properties) -> 高级(Advanced) 中的“为下列客户端动态分配IP地址”默认的 DHCP(H) 改为两者(B)。虽然我试过在我的环境中无论设置为哪个各项操作都正常，但为防止意外，感觉还是有必要提醒下。如下图：

(, 下载次数: 78)

第（一）部分内容到此结束。为便于区分章节，请各看官移步 3 楼继续观看教程第（二）部分…

作者: imyz 时间: 2024-3-12 13:50
标题: （二）iPXE 定制化配置与脚本
本帖最后由 imyz 于 2024-3-18 21:53 编辑

对 iPXE 的定制化配置与脚本早烂熟于胸的，可直接跳过这部分内容，而对于刚开始接触的，在开始之前我还是先介绍下基本概念，避免盲目操作。之前提到过 Windows 能够进行 iSCSI 安装及引导的关键在于一个唤作 iBFT 的东西，而 iPXE 是就用来从无到有地创建它，而 iPXE 创建 iBFT 又是依据一个唤作“root-path 根路径” 的东西，在 DHCP 中对应的就是 Option 017，iPXE 官网 iPXE - open source boot firmware [sanuri] 是这样描述的：

iSCSI
The format of an iSCSI SAN URI is defined by RFC 4173. The general syntax is:
iscsi:<servername>:<protocol>:<port>:<LUN>:<targetname>

   所以，root-path 其实就是由 RFC-4173 定义的 SAN-URI (Storage Area Network – Uniform Resource Identifier)，翻译过来就是“存储区域网络统一资源标识符”。相信大家应该知道网站的链接地址叫作 URL – 统一资源定位符，但可能不一定会知道 URI，也没关系，我也不是很清楚，可以简单地认为 URI = URL + URN，它的语法由 RFC-3986 定义，大家有兴趣可以去认真学习下，此处不展开，还是回到主题。

   虽然知道了 root-path 的语法，但实际上要如何表达还是用我 WinServer 2022 虚拟机创建的 iSCSI Target 举个实例更加直观，先来看图：

(, 下载次数: 76)

   已知我 iSCSI Target 的目标 IQN 为 iqn.1991-05.com.microsoft:vdc-ipxe，其 IP 地址为 10.1.1.10，那我的 root-path 就应当是：

iscsi:10.1.1.10::::iqn.1991-05.com.microsoft:vdc-ipxe

复制代码

知道 root-path 根路径如何配置后还不能开心得太早，因为不排除部分厂商的 iSCSI Target 有可能不允许将 CHAP 身份认证留空，或者对 Initiator IQN 有一定的格式要求，这里再以我上图中高亮那个的 iSCSI Target 为例，已知其 CHAP 用户名 = imyz、密码 = iscsi-target、限定 Initiator IQN 发起 ID = iqn.vm.ipxe，那么在进入 iPXE 环境后，想顺利地“sanhook”勾搭上这类的就必须使用以下的基本命令：

set username <iSCSI CHAP 认证用户名>
set password <iSCSI CHAP 认证密码>
set initiator-iqn <你 PC 的 Initiator 发起 IQN>
set root-path <你自己的 root-path>
sanhook ${root-path}

复制代码

   以上命令执行成功的话将如下图所示：

(, 下载次数: 86)

   讲到这里就很自然地引出了在教程（一）DHCP 配置部分开篇讲到的，我最终没有按照 iPXE 官网的方法将 root-path 直接配置在 DHCP Option 017 中，就是因为上面大家所看见的，iPXE 可以通过命令行的方式来执行自己所需要的指令，假如可以将这些指令写到脚本中让 iPXE 在恰当的环节自动执行，那么无疑对今后的调整与维护都是极大的灵活度，比如：改密码，甚至换 SAN-URI 硬盘（换操作系统）仅须打开脚本改下 root-path 即可，而不必再去配置 DHCP 服务器。所以，接下来又很自然地引出 iPXE 的脚本与启动菜单，而这部分内容并不是我的原创，而且每个人的需求与喜好也不同，请大家多看看官网的文档：

脚本：iPXE - open source boot firmware [scripting]
菜单：iPXE - open source boot firmware [cmd:menu]

   我在这里只是抛砖引玉，将我自己模拟环境中用到的脚本和菜单打包分享给各位，我已经反复测试过多次，只要按教程上面各项正确配置就一定是能够成功执行的，唯一需要向不熟悉 iPXE 的看官提前交待一下的是：iPXE 官方不支持 if 语句，就是说脚本和菜单均不支持条件判断，至少我了解目前不支持，而我一开始也不清楚这个限制，在写脚本时就按照 Shell 的习惯，所以才有了 sanhook.ipxe 脚本中以下这段看起来有点绕的写法，我稍解释下以免刚接触的看官摸不着头脑不知从何改起：

set san-drive 128 # 128 = 0x80
set san-target${san-drive} iqn.1991-05.com.microsoft:vdc-test
set root-path${san-drive} iscsi:${san-server}::::${san-target${san-drive}}
sanhook -d ${san-drive} ${root-path${san-drive}}
inc san-drive
set san-target${san-drive} iqn.1991-05.com.microsoft:vdc-ipxe
set root-path${san-drive} iscsi:${san-server}::::${san-target${san-drive}}
sanhook -d ${san-drive} ${root-path${san-drive}}

复制代码

   以上代码用途是先后连接两个 SAN-URI。第一行是将 config 中的 san-drive 赋值为十进制 128，即十六进制 0x80，这是沿用 sanhook 不带 -d 参数时默认使用的起始设备编号；第二行 set san-target${san-drive} 是创建一个 config 中不存在的名为“san-target0x80”的新变量并初始化为 iqn.xxx；第三行是将上面的各项拼装成 SAN-URI 格式，并将其赋值给新创建的名为 root-path0x80 的变量，注意最后是嵌套的调用方式；第四行就利用上述各变量值连接第一个 SAN-URI。第五行 inc san-drive 等价于 C 语言中的 san-drive++，执行结果就是 san-drive=0x81，随后的代码作用就和前面二/三/四行完全一样。若在命令行中手工执行 sanhook.ipxe 脚本，其效果如下图所示：

(, 下载次数: 67)

   讲到这里又不得不再强调一下，虽然脚本可以实现一次执行连接多个 iSCSI Target 磁盘，但在安装阶段却不建议这样做，原因在我 NUC9 iSCSI 帖中也提到过了，假如其它磁盘中有一个或多个存在 EFI 引导分区的情况下，则有可能导致安装失败，而待安装完成之后则不会有这个问题，具体如何各位可自行尝试。总体上讲脚本和菜单语法并不复杂，但凡能看懂英文的应该一看就会修改了，加上现在浏览器绝大部分都支持翻译功能，相信应当难不倒各位。所以，连载的（上）篇到此就准备草草收场了，我也好多抽出空来继续准备（下）篇的内容。下图是客户机开机后，从 DHCP 策略下发给 iPXE 自动加载的菜单（Boot\iPXE\menu.ipxe）效果：

(, 下载次数: 78)

   节目的最后奉上我使用的 iPXE 启动文件、脚本/菜单、vmxnet3 驱动等。鉴于云盘商的限制，文件与之前一样采用 7-Zip 压缩为自解压包 iPXE-WDS.exe：

https://www.alipan.com/s/nVkryM4XzF6
提取码: k9c2

---------- 2024/03/18 增补 ----------
   因（上）是在我正在进行 Linux 篇测试过程中临时决定先发的，这样好让我专注于 Linux。不过弊端也是明显的，即：多次打补丁。正是因为临时起意，所以当时提供的 vmxnet3 的驱仅有 Win11 的，所以，在今天上午发布的（下）篇中加入了 Win10 x86 + x64，合计三个版本。以下是（下）篇的附件：

iPXE-Linux-Updated.exe
https://www.alipan.com/s/f5mFaHn8sUy
提取码: ni53
---------- 增补结束 ----------

   最后，致敬 iPXE团队的无私与辛勤付出！

作者: rfven 时间: 2024-3-12 16:30
4点半了,歇够了吗?

催更Linux + wimboot

作者: gravely 时间: 2024-3-12 17:45
如果本来就有路由器做DHCP服务器，iPXE会冲突吗？

作者: jame 时间: 2024-3-12 18:34
试试能回复不~

作者: imyz 时间: 2024-3-12 18:52
本帖最后由 imyz 于 2024-3-12 18:56 编辑

回留言不行，再试下跟自己帖。。。。这就有点尴尬了不是？

先在这里回 1楼：就知道剧透有风险！！现在（下）还没开始动笔，还得再测试几轮，准备素材等等...

回 2楼：假如你的路由器是 OperWRT 这种可以定制 dnsmasq 的，那么答案就是可以的。若自己不知道如何操作的，则请耐心等待（下）篇。谢谢

作者: gaoyi124 时间: 2024-3-12 18:55
专业,给我的gen8部署一下,以后内网调试机器装系统啥的,是不是就不用u盘pe系统了

作者: k8qxt5 时间: 2024-3-13 01:18
lz研究一下 iventoy

作者: imyz 时间: 2024-3-13 09:05

k8qxt5 发表于 2024-3-13 01:18
lz研究一下 iventoy

好的。我有时间去学习下。谢谢

作者: imyz 时间: 2024-3-13 09:10

rfven 发表于 2024-3-12 16:30
4点半了,歇够了吗? 催更Linux + wimboot

刚在水区看盆友留言才晓得原来 CHH 还有回不了帖的 Bug，得进高级模式...

回看官：这几天等再多测试下确定没问题后再开始写教程... 我这人懒，还请多点耐心

作者: imyz 时间: 2024-3-13 09:19

gravely 发表于 2024-3-12 17:45
如果本来就有路由器做DHCP服务器，iPXE会冲突吗？

若是一般的家用路由器，假如能进管理页面将其单独关闭的话，就可以按我这个教程操作。因为我手上没有现成的硬件无法实测，但理论上是可行的。

假如你的路由器是能够像 OpenWRT 那种可以自己定制 DHCP 服务，并且恰好你不清楚如何配置 DHCP 的话，那么请再多点耐心等（下）篇 Linux + wimboot。谢谢

作者: rfven 时间: 2024-3-13 11:27

imyz 发表于 2024-3-13 09:10
刚在水区看盆友留言才晓得原来 CHH 还有回不了帖的 Bug，得进高级模式...

回看官：这几天等再多测试下确 ...

看过类似的,在PE实现
https://space.bilibili.com/14597170/video

作者: imyz 时间: 2024-3-13 12:11

gaoyi124 发表于 2024-3-12 18:55
专业,给我的gen8部署一下,以后内网调试机器装系统啥的,是不是就不用u盘pe系统了 ...

iPXE 不仅支持内网，它还可以 chain 到一个 Http/https 网站.... 所以想像空间蛮大

作者: imyz 时间: 2024-3-13 12:18

rfven 发表于 2024-3-13 11:27
看过类似的,在PE实现
https://space.bilibili.com/14597170/video

感谢分享！刚看了那位大佬其中关于 iSCSI 的视频，感觉全是基于深度定制之后的系统，并且其中使用了不少微软官方以外的第三方工具，比如：TinyPXEServer、CDI 等等.... 能把 WinPE 玩成那样的的确是个技术大牛。

相比之下，我这个就是“极简版”，除 iPXE 绕不开外，全程不使用微软官方以外的任何第三方工具，可能适合更喜欢“纯净”环境的人吧。

作者: gravely 时间: 2024-3-14 10:06
DHCP服务器是华为交换机.....主路由是OP，先看看楼主下篇......

作者: imyz 时间: 2024-3-18 11:00

rfven 发表于 2024-3-12 16:30
4点半了,歇够了吗? 催更Linux + wimboot

（下）刚发了，还热乎着

作者: imyz 时间: 2024-3-18 11:01

gravely 发表于 2024-3-14 10:06
DHCP服务器是华为交换机.....主路由是OP，先看看楼主下篇......

看官现在可移步：https://www.chiphell.com/thread-2591618-1-1.html

作者: 不超频没意思 时间: 2024-4-30 14:02
有点复杂得慢慢研究了

作者: CYF19991203 时间: 2025-3-13 20:28
emm，自己走了一遍，但是sanboot 老是失败是iscsi 目标盘有什么规则限制吗?

作者: imyz 时间: 2025-3-17 09:11

CYF19991203 发表于 2025-3-13 20:28
emm，自己走了一遍，但是sanboot 老是失败是iscsi 目标盘有什么规则限制吗?

请问你的是虚拟机还是实体机环境？假如是 VMware 虚拟机，我早期在 VMware Workstation 16 那时尝试过用 iPXE，但只要是在 UEFI 模式中都是失败，而用 Legacy BIOS 就可以成功。后来问了开发者，人家答复说是当时 VMware 的 UEFI 有 Bug（详见下面截图），既开发人员都这么讲那只能等后续版本更新，也正是因为这样才有了后来我那篇纯 Windows 环境下的 NUC9 iSCSI无盘工作站/服务器札记。

假如是实体机，这可能得看你的错误的具体代码、提示等。

(, 下载次数: 13)

欢迎光临 Chiphell - 分享与交流用户体验 (https://www.chiphell.com/)