原先的 PXE 引导中，两阶段的 PXELINUX 的区别，以及 iPXE 的用途？

[崔灏 (CUI Hao)]

以前的 PXE 引导过程是这样的：
<网卡 PXE rom>
1、请求 DHCP
2、从 TFTP 上加载并引导指定的PXE程序（/tftpboot/pxelinux.0）
<PXELINUX>
3、pxelinux.0 加载 TFTP 上的配置文件（按MAC地址、IP地址）
4、按默认配置文件：
LABEL ipxe
KERNEL pxechain.com
APPEND 202.38.93.95::ipxelinux.0
接着引导 ipxelinux.0，即iPXE程序。
<iPXE>
5、执行硬编码进去的脚本（http://202.38.93.95/boot/boot.php，这里PHP没用，脚本确实是硬编码的）
6、通过 HTTP 引导 http://202.38.93.95/boot/bin/pxelinux.bin，并传给 PXELINUX
两个参数，分别指定 PXELINUX 配置文件和工作目录。
<PXELINUX 2>
7、PXELINUX 通过 HTTP 获取动态的配置文件，并呈现给用户。
8、用户选择菜单项，完毕～

这里有一些问题：
a、第一个 PXELINUX 和第二个 PXELINUX 有何不同？为什么前一个阶段的 PXELINUX 不能直接通过 HTTP
协议获取菜单？是因为没有办法传给第一阶段的 PXELINUX 参数吗？
b、中间的 iPXE 是干什么的？如果是因为要传那两个参数，那么不能直接用前一阶段的 PXELINUX 传给后一阶段的 PXELINUX
吗？或者是因为当时 PXELINUX 功能的局限？

--
崔灏 / CUI Hao
Homepage: http://cuihao.tk/
Twitter: @cuihaoleo

[崔灏 (CUI Hao)]

由于不清楚各个阶段的程序格式、工作方式（HTTP/TFTP）、网络参数（是否需要dhcp），尝试用新版syslinux替换旧程序时遇到了很多麻烦。

问题a提到两个PXELINUX程序的区别。我用新版 syslinux 提供的 pxelinux.0 替换前一阶段的
pxelinux.0，几乎没有任何问题。但后一阶段的 pxelinux.bin，替换后就会出现问题（VBox直接崩溃）。

我查了一些资料，新版 PXELINUX 中的一个叫 lpxelinux.0 的程序确实是直接支持 HTTP 协议的。中间的 iPXE
现在我给直接跳过去了，改成这样引导：

<网卡 PXE rom>
1、请求 DHCP
2、从 TFTP 上加载并引导指定的PXE程序（/tftpboot/pxelinux.0）

<PXELINUX（pxelinux.0）>

3、pxelinux.0 加载 TFTP 上的配置文件（按MAC地址、IP地址）
4、按默认配置文件：

LABEL lpxe
KERNEL pxechn.c32
APPEND lpxelinux.0 -c http://pxe.ustc.edu.cn/boot/menu.cgi -p
http://pxe.ustc.edu.cn/boot/bin/
接着引导 lpxelinux.0，即支持 HTTP 协议的 PXELINUX 程序。
两个参数，分别指定 PXELINUX 配置文件和工作目录。
<PXELINUX（lpxelinux.0）>
5、PXELINUX 通过 HTTP 获取动态的配置文件，并呈现给用户。
6、用户选择菜单项，完毕～

新版 syslinux 里没有 pxechain.com，转而有一个 pxechn.c32。根据官方文档，这个可以直接给 lpxelinux.0 传参数。

[Zhang Cheng]

​首先需要理清楚几个概念：pxe, ipxe, pxelinux，以及几个名词：pxelinux.0, ipxelinux.0

* pxe是一个协议，跟mbr是一个性质的东西，它规定了CPU启动后通过什么方式获取引导代码并执行。

* pxe的实现有许多，不同的厂商有不同的实现。并且pxe的实现代码主要有两种存放位置，一种是存在主板上，一种是存在网卡里，现在新的网卡一般都自带了pxe的实现代码。（去mbr查找引导代码的实现是在主板上的。）

* 由于pxe协议比较“落后”，仅支持tftp传输数据，性能差，灵活性也差，于是有了gpxe这个项目。gpxe是一种兼容pxe的实现，并且在pxe之上增加了许多特性，例如通过http/ftp等协议传输数据。

* gpxe原先使用的域名的拥有者突然收回了该域名的使用权，于是这些人fork出去做了ipxe，gpxe现在已经不再开发，ipxe开发非常活跃。

* 一些较新的intel的网卡里都带了gpxe的实现代码，最新的可能会带ipxe代码。

* pxelinux是syslinux项目的一个部分，syslinux主要有三个产出，syslinux、isolinux、pxelinux，分别用于硬盘、光盘、网络启动，它的角色与grub相同。

* *.bin 和 *.0 文件一般是一样的，不过使用上有一些区别，下面解释

* pxelinux.bin 是 pxelinux 编译后生成的文件

​* 由于大多数网卡、主板都不自带gpxe/ipxe的代码，所以通常引导时需要这样的途径： pxe -> ipxe -> pxelinux.bin，后面这两步可以合并，于是大家就把ipxe与pxelinux.bin​的代码合体，做成了 ipxelinux.0 （gpxe+pxelinux.bin = gpxelinux.0）。一般习惯上裸的pxelinux镜像用.bin后缀，加上gpxe/ipxe之后用.0后缀。此外还会有.lkrn后缀，这是ipxe的东西，ipxe的代码默认只能通过pxe协议的方式加载，他们搞了另外一个代码入口，使得可以通过像linux kernel的方式一样加载（就是可以通过grub引导），这种镜像的后缀是lkrn.

* 所以可行的引导过程可以有这些：

  - pxe(网卡) -> ipxe -> pxelinux.bin -> menu.c32

  - pxe      -> ipxelinux.0 -> menu.c32

  - pxe -> syslinux.bin -> ipxe -> pxelinux.bin -> menu.c32

  - pxe -> syslinux.bin -> ipxelinux.0 -> menu.c32

  - grub -> ipxe.lkrn -> pxelinux.bin -> menu.c32

  - grub -> ipxelinux.lkrn -> menu.c32

  - ipxe(烧入网卡) -> pxelinux.bin

  - ...

由于pxe代码是主板、网卡自带的，所以兼容性最好（至少本机的代码兼容本机的设备）。而ipxe兼容性略差（只是相对来说，因为我们编译时可能会漏掉一些网卡，或者一些特殊问题不好解决），曾经尝试过直接一步 pxe -> ipxelinux.0，但是发现有一些机器无法启动，加载ipxe之后就停住了。所以后来退而求其次，用两步加载，对于ipxe不支持的设备，可以在第一步pxe->pxelinux.bin之后手快一些按任意键中断，然后仍然可以使用pxe，不过之后我们一直没有维护通过tftp加载的pxelinux以及配置文件，所以那部分内容其实现在都已经严重过时了。

Cheng,

Best Regards

[Zhang Cheng]

​关于版本，ipxe和syslinux这两年都开发的非常快，版本升了很多，feature也变了很多，特别是syslinux变化非常大，syslinux现在将大多数功能都抽出来放到com32模块里了（.c32文件）。

原来的pxe，我在升级ipxe的时候，尽量保持了所有原来的东西，原来的pxelinux.bin的版本都保留了，以免在升级中出现太大的问题，好歹能留个fallback。这也是两步加载的原因，第一步加载的是我接手前的pxelinux.bin，然后再加载我自己编译的ipxelinux.0。

现在搞开发的话，我觉得也还是保留两步加载，不过两步的pxelinux.bin可以用相同版本的，pxelinux.bin基本没有硬件兼容性（它不需要直接跟网卡打交道），并为第一步加载的pxelinux.bin准备一些静态的pxelinux.cfg，使得一些老旧设备仍然可以使用。第二步再加载新的ipxelinux.bin。

pxechain.c32是什么东西呢？注意，syslinux跟grub是一样的，它默认以加载内核的方式来加载所有的东西，而ipxe镜像是pxe协议的，必须要通过pxe的方式来加载，也就是从syslinux -> ipxe的加载必须用pxechain的方式。我印象中现在syslinux将加载linux内核的功能也抽出来做了一个linux.c32，而不是内置了，所以说它越来越模块化了。我不清楚最新版的pxelinux里面是否还有pxechain.c32了，但肯定有类似的东西来完成这件事，你主要需要理解的是这里为何需要一个这样的东西。（其实在很早的时候有一段时间pxelinux可以直接加载ipxe的，但后来两边都规范化后，就必须通过pxechain了。）

协议方面，通过pxe引导的pxelinux，仅能通过tftp加载东西。通过ipxe引导的pxelinux则灵活很多。

​

2014-06-18 17:06 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

​首先需要理清楚几个概念：pxe, ipxe, pxelinux，以及几个名词：pxelinux.0, ipxelinux.0

* pxe是一个协议，跟mbr是一个性质的东西，它规定了CPU启动后通过什么方式获取引导代码并执行。

* pxe的实现有许多，不同的厂商有不同的实现。并且pxe的实现代码主要有两种存放位置，一种是存在主板上，一种是存在网卡里，现在新的网卡一般都自带了pxe的实现代码。（去mbr查找引导代码的实现是在主板上的。）

* 由于pxe协议比较“落后”，仅支持tftp传输数据，性能差，灵活性也差，于是有了gpxe这个项目。gpxe是一种兼容pxe的实现，并且在pxe之上增加了许多特性，例如通过http/ftp等协议传输数据。

* gpxe原先使用的域名的拥有者突然收回了该域名的使用权，于是这些人fork出去做了ipxe，gpxe现在已经不再开发，ipxe开发非常活跃。

* 一些较新的intel的网卡里都带了gpxe的实现代码，最新的可能会带ipxe代码。

* pxelinux是syslinux项目的一个部分，syslinux主要有三个产出，syslinux、isolinux、pxelinux，分别用于硬盘、光盘、网络启动，它的角色与grub相同。

* *.bin 和 *.0 文件一般是一样的，不过使用上有一些区别，下面解释

* pxelinux.bin 是 pxelinux 编译后生成的文件

​* 由于大多数网卡、主板都不自带gpxe/ipxe的代码，所以通常引导时需要这样的途径： pxe -> ipxe -> pxelinux.bin，后面这两步可以合并，于是大家就把ipxe与pxelinux.bin​的代码合体，做成了 ipxelinux.0 （gpxe+pxelinux.bin = gpxelinux.0）。一般习惯上裸的pxelinux镜像用.bin后缀，加上gpxe/ipxe之后用.0后缀。此外还会有.lkrn后缀，这是ipxe的东西，ipxe的代码默认只能通过pxe协议的方式加载，他们搞了另外一个代码入口，使得可以通过像linux kernel的方式一样加载（就是可以通过grub引导），这种镜像的后缀是lkrn.

* 所以可行的引导过程可以有这些：

  - pxe(网卡) -> ipxe -> pxelinux.bin -> menu.c32

  - pxe      -> ipxelinux.0 -> menu.c32

  - pxe -> syslinux.bin -> ipxe -> pxelinux.bin -> menu.c32

  - pxe -> syslinux.bin -> ipxelinux.0 -> menu.c32

  - grub -> ipxe.lkrn -> pxelinux.bin -> menu.c32

  - grub -> ipxelinux.lkrn -> menu.c32

  - ipxe(烧入网卡) -> pxelinux.bin

  - ...

由于pxe代码是主板、网卡自带的，所以兼容性最好（至少本机的代码兼容本机的设备）。而ipxe兼容性略差（只是相对来说，因为我们编译时可能会漏掉一些网卡，或者一些特殊问题不好解决），曾经尝试过直接一步 pxe -> ipxelinux.0，但是发现有一些机器无法启动，加载ipxe之后就停住了。所以后来退而求其次，用两步加载，对于ipxe不支持的设备，可以在第一步pxe->pxelinux.bin之后手快一些按任意键中断，然后仍然可以使用pxe，不过之后我们一直没有维护通过tftp加载的pxelinux以及配置文件，所以那部分内容其实现在都已经严重过时了。

--

Cheng,

Best Regards

[Zhang Cheng]

关于DHCP的配置，大致是这样的：

* 第一步，从网卡启动pxe，这一步根据协议必须要走DHCP，以或许启动文件（也就是pxelinux.bin）

* 第二步，加载ipxe，这时有两种方案：

  - ipxe代码也DHCP一次，获取启动文件。在DHCP服务器上需要配置，如果发现客户端是pxe，返回一个东西，如果发现客户端是ipxe，返回另外一个东西

  - ipxe编译时内置一份配置文件，告知启动文件，这时ipxe仍需要DHCP一下以获取ip地址，然后就根据内置的配置来选择下一步加载什么

我当时使用的是第二种方式，也就是ipxe里面内嵌了配置（我记得似乎没有内嵌pxelinux.0）。

此外，ipxe本身也支持直接引导内核，也有比较简单的菜单系统，不过一般我们不用他，毕竟不好用。早期ipxe支持直接引导syslinux的.c32文件，这其实也困扰了我很久，使得我一直没有搞清楚ipxe/syslinux/com32之间的关系，后来ipxe不支持直接引导com32文件了，必须先加载syslinux，再由syslinux引导com32文件，至此我才真正搞清楚他们之间的关系。

科大的pxe可以考虑用vesamenu.c32代替menu.c32，这两个完全相同，区别在于vesamenu.c32支持设置背景图片（我当时其实想搞一个每次启动随机图片的，但是没有人做图。。。）vesamenu.c32可能存在一些兼容性问题，某些机器上可能用不了，不过我想这样的机器毕竟太少了。

以前做pxe时，也有过一个新闻系统的想法，并且在公网上也见到有人这么做了，不过那个东西后来似乎死掉了。大致是这样的，用vesamenu.c32，首先将新闻制作成图片（肯定是程序做的），配合菜单，就可以自行浏览。大致这样想：

- 例如新闻的目录，一页有10条新闻标题，一条一行，左边距大一些

- 菜单设置宽度小一些，2个字符宽左右，位置在左边，菜单项都不需要文字，菜单有10个选项，每个选项的位置正好对应背景图片上10个新闻的标题

- 当按上下键时，被选中的菜单就是一个很短的亮条，在对应的新闻标题左边，所以有选择的效果

- 回车后，后台根据选中的新闻，将对应新闻内容的图片加载出来，这一页其实还是vesamenu.c32，有一个后退选项，如果需要的话也可以有下一页之类的选项

- 上述新闻可以换成任何东西，比如天气预报，bbs之类的

这就是一个非常简单的信息浏览平台了。

--

Cheng,

Best Regards

[崔灏 (CUI Hao)]

嗯，也就是说，ipxe主要是为了扩展pxelinux功能。但现在似乎直接引导的pxelinux有了些新功能。

我在2楼提到的 lpxelinux.0（是 L 不是 I，和ipxe无关），似乎是 syslinux
新添加的东西，它可以”直接通过HTTP获取文件“。因为这个文件就是 syslinux 直接提供的（并非第三方的），所以我认为它的驱动和
PXELINUX 是一样的。

这里说的 ”直接通过HTTP获取文件“，就像这样（放到TFTP里，我刚刚实验可行的）：
LABEL lpxe
KERNEL menu.c32
APPEND http://pxe.ustc.edu.cn/boot/menu.cgi
然后就可以直接显示 HTTP 上获取的菜单。

刚刚实验成功的这个例子就意味着，现在不需要任何其他的引导步骤，就可以通过HTTP显示PXE菜单了：
网卡PXE -> lpxelinux.0 -> HTTP获取的菜单，用户进行下一步选择

之前您所提到的“通过pxe引导的pxelinux，仅能通过tftp加载东西”，这个 lpxelinux.0 应该已经完全克服了。

> --
> -- 来自USTC LUG
> 请使用gmail订阅，不要灌水。
> 更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "USTC_LUG" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ustc_lug+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Zhang Cheng]

2014-06-18 18:53 GMT+08:00 崔灏 (CUI Hao) <cuiha...@gmail.com>:

嗯，也就是说，ipxe主要是为了扩展pxelinux功能。但现在似乎直接引导的pxelinux有了些新功能。

我在2楼提到的 lpxelinux.0（是 L 不是 I，和ipxe无关），似乎是 syslinux
新添加的东西，它可以”直接通过HTTP获取文件“。因为这个文件就是 syslinux 直接提供的（并非第三方的），所以我认为它的驱动和
PXELINUX 是一样的。

这里说的 ”直接通过HTTP获取文件“，就像这样（放到TFTP里，我刚刚实验可行的）：
    LABEL lpxe
    KERNEL menu.c32
    APPEND http://pxe.ustc.edu.cn/boot/menu.cgi
然后就可以直接显示 HTTP 上获取的菜单。

刚刚实验成功的这个例子就意味着，现在不需要任何其他的引导步骤，就可以通过HTTP显示PXE菜单了：
    网卡PXE -> lpxelinux.0 -> HTTP获取的菜单，用户进行下一步选择

之前您所提到的“通过pxe引导的pxelinux，仅能通过tftp加载东西”，这个 lpxelinux.0 应该已经完全克服了。

​很久没关注syslinux了，现在看来，syslinux简直屌爆了！​

--

Cheng,

Best Regards

[Bojie Li]

问个小白问题，为什么不能让 PXE 用 tftp 协议加载 pxelinux.bin，然后 pxelinux.bin 加载 menu.c32 模块，显示菜单呢？

感觉这里绕来绕去就是为了使用 http 协议。tftp 协议真的那么不好吗？我看了一下，tftp 的文件传输部分相当于窗口大小恒定为 1、数据包大小恒定为 512 字节的 TCP 协议。在学校里毫秒级的延迟情况下，几十 KB 的 pxelinux.bin 只要 100~200 毫秒就能下载完。tftp 也是支持文件名的，为什么说 “灵活性差”？

2014-06-18 17:06 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

--

[Zhang Cheng]

2014-06-20 0:28 GMT+08:00 Bojie Li <boj...@gmail.com>:

问个小白问题，为什么不能让 PXE 用 tftp 协议加载 pxelinux.bin，然后 pxelinux.bin 加载 menu.c32 模块，显示菜单呢？

感觉这里绕来绕去就是为了使用 http 协议。tftp 协议真的那么不好吗？我看了一下，tftp 的文件传输部分相当于窗口大小恒定为 1、数据包大小恒定为 512 字节的 TCP 协议。在学校里毫秒级的延迟情况下，几十 KB 的 pxelinux.bin 只要 100~200 毫秒就能下载完。tftp 也是支持文件名的，为什么说 “灵活性差”？

​tftp主要有两个问题：

* 下载速度非常慢​，大概只有2MB/s的速度。以前用tftp的时候，加载一个debian installer initrd.gz要10s左右，图书馆查询机当时是一个rootfs.tgz（100MB左右）通过tftp加载，速度就更加不能忍了。下面是我在千兆内网做的测试：

   $ tftp 192.168.10.150

   tftp> get zero

   Received 104857600 bytes in 51.7 seconds

* tftp的服务端很弱。换成http之后，配置文件一类的东西就可以“动态化”，后端可以用php、python等，于是可以做更多的事情，例如根据客户端ip返回不同的内容，根据客户端的mac返回不同的内容（例如可以允许每个用户自定义自己的菜单），一旦后端可以动态化，那么可以玩的事情就很多了。

--

Cheng,

Best Regards

[Bojie Li]

2014-06-20 0:39 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

2014-06-20 0:28 GMT+08:00 Bojie Li <boj...@gmail.com>:

问个小白问题，为什么不能让 PXE 用 tftp 协议加载 pxelinux.bin，然后 pxelinux.bin 加载 menu.c32 模块，显示菜单呢？

感觉这里绕来绕去就是为了使用 http 协议。tftp 协议真的那么不好吗？我看了一下，tftp 的文件传输部分相当于窗口大小恒定为 1、数据包大小恒定为 512 字节的 TCP 协议。在学校里毫秒级的延迟情况下，几十 KB 的 pxelinux.bin 只要 100~200 毫秒就能下载完。tftp 也是支持文件名的，为什么说 “灵活性差”？

​tftp主要有两个问题：

* 下载速度非常慢​，大概只有2MB/s的速度。以前用tftp的时候，加载一个debian installer initrd.gz要10s左右，图书馆查询机当时是一个rootfs.tgz（100MB左右）通过tftp加载，速度就更加不能忍了。下面是我在千兆内网做的测试：

   $ tftp 192.168.10.150

   tftp> get zero

   Received 104857600 bytes in 51.7 seconds

用 TFTP 加载大文件当然不行啦，因为 TFTP 是一个“停等”协议，上个数据的确认不到，下个数据就不能发，如果有 2 MB/s 的速度，512 字节一个包，说明每秒能传 4 K 个包，也就是往返延迟（RTT）只有 0.25 ms，这非常好啦。

但我质疑的是用 pxe 加载 pxelinux，中间为什么要加入 ipxe 一步。用户选择菜单之后，pxelinux 加载的应该是操作系统的内核和 initrd，wheezy 的 netboot 分别是 2.8 MB 和 10.7 MB，这种大小的文件确实不适合 tftp 协议了。不过 pxelinux 应该能实现 HTTP 协议吧，由于多了个 TCP，开发起来可能比 tftp 麻烦一些。

 

* tftp的服务端很弱。换成http之后，配置文件一类的东西就可以“动态化”，后端可以用php、python等，于是可以做更多的事情，例如根据客户端ip返回不同的内容，根据客户端的mac返回不同的内容（例如可以允许每个用户自定义自己的菜单），一旦后端可以动态化，那么可以玩的事情就很多了。

我觉得这纯粹是为了用上 FastCGI 吧。像我这种裸写 socket 的，实现 TFTP 和 HTTP 的难度感觉差不多，TFTP 走的是 UDP/IP，当然也能看到客户端 IP、MAC。

[Zhang Cheng]

2014-06-20 1:02 GMT+08:00 Bojie Li <boj...@gmail.com>:

用 TFTP 加载大文件当然不行啦，因为 TFTP 是一个“停等”协议，上个数据的确认不到，下个数据就不能发，如果有 2 MB/s 的速度，512 字节一个包，说明每秒能传 4 K 个包，也就是往返延迟（RTT）只有 0.25 ms，这非常好啦。

但我质疑的是用 pxe 加载 pxelinux，中间为什么要加入 ipxe 一步。用户选择菜单之后，pxelinux 加载的应该是操作系统的内核和 initrd，wheezy 的 netboot 分别是 2.8 MB 和 10.7 MB，这种大小的文件确实不适合 tftp 协议了。不过 pxelinux 应该能实现 HTTP 协议吧，由于多了个 TCP，开发起来可能比 tftp 麻烦一些。

​pxelinux也是最近（大概去年的样子吧）才实现了自己的HTTP协议栈，也就是前面说的lpxelinux.bin，以前都是不带http协议栈，因此依赖于ipxe。

 

 

* tftp的服务端很弱。换成http之后，配置文件一类的东西就可以“动态化”，后端可以用php、python等，于是可以做更多的事情，例如根据客户端ip返回不同的内容，根据客户端的mac返回不同的内容（例如可以允许每个用户自定义自己的菜单），一旦后端可以动态化，那么可以玩的事情就很多了。

我觉得这纯粹是为了用上 FastCGI 吧。像我这种裸写 socket 的，实现 TFTP 和 HTTP 的难度感觉差不多，TFTP 走的是 UDP/IP，当然也能看到客户端 IP、MAC。

​简单的说是的。复杂的说，http是一个广泛应用的协议，使用http，那后端就爱干啥干啥了，反正给一个url，吐一堆数据就行了，甚至bash脚本都可以做后端。而tftp做不到这一点（如果要做，基本上就是自己实现一个tftp server了，而不像http应用那样，http本身由库解决，开发者仅关注业务逻辑）。另外，通过tftp并不能一定看到客户端的mac地址，因为有NAT。HTTP也是无法看到的，但配合ipxe就可以实现，ipxe可以读到mac地址，在请求配置文件时将mac地址作为参数就可以了。之前我维护的那一版的ipxe请求boot.php时都是带着mac地址的，虽然一直没有用上。（之前有一个想法是，对于一个live系统，可以提供多个内核，分别为不同vendor的电脑优化，客户端请求时，可以根据mac地址大致的确定vendor，并返回一个合适的内核。）

--

Cheng,

Best Regards

[Bojie Li]

2014-06-20 1:15 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

​简单的说是的。复杂的说，http是一个广泛应用的协议，使用http，那后端就爱干啥干啥了，反正给一个url，吐一堆数据就行了，甚至bash脚本都可以做后端。而tftp做不到这一点（如果要做，基本上就是自己实现一个tftp server了，而不像http应用那样，http本身由库解决，开发者仅关注业务逻辑）。另外，通过tftp并不能一定看到客户端的mac地址，因为有NAT。HTTP也是无法看到的，但配合ipxe就可以实现，ipxe可以读到mac地址，在请求配置文件时将mac地址作为参数就可以了。之前我维护的那一版的ipxe请求boot.php时都是带着mac地址的，虽然一直没有用上。（之前有一个想法是，对于一个live系统，可以提供多个内核，分别为不同vendor的电脑优化，客户端请求时，可以根据mac地址大致的确定vendor，并返回一个合适的内核。）

应该是经过了路由器就看不到 MAC，经过了 NAT 就看不到 IP 吧。

根据 MAC 地址的前三个字节（OUI）查到的是网卡的 vendor 吧，怎么查到机器的 vendor？

[Bojie Li]

2014-06-20 1:15 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

​pxelinux也是最近（大概去年的样子吧）才实现了自己的HTTP协议栈，也就是前面说的lpxelinux.bin，以前都是不带http协议栈，因此依赖于ipxe。

操作系统（如 Debian netboot installer）的内核是 ipxe 还是 pxelinux 负责加载？ipxe 启动 pxelinux 之后，pxelinux 还能调用 ipxe 的 http 模块下载文件吗？

[Zhang Cheng]

2014-06-20 1:24 GMT+08:00 Bojie Li <boj...@gmail.com>:

应该是经过了路由器就看不到 MAC，经过了 NAT 就看不到 IP 吧。

​​

啊，

​说错了。​

 

根据 MAC 地址的前三个字节（OUI）查到的是网卡的 vendor 吧，怎么查到机器的 vendor？

​网上应该能找到一些数据库，根据品牌机的网卡mac能查到机器的厂商。不过这个肯定不是非常靠谱的事情。ipxe应该是可以读到一些机器的信息的，也许可以直接读到机器的vendor name（没有确认），在请求配置时都可以传上去。

--

Cheng,

Best Regards

[Zhang Cheng]

2014-06-20 1:27 GMT+08:00 Bojie Li <boj...@gmail.com>:

操作系统（如 Debian netboot installer）的内核是 ipxe 还是 pxelinux 负责加载？ipxe 启动 pxelinux 之后，pxelinux 还能调用 ipxe 的 http 模块下载文件吗？

​ipxe支持直接加载操作系统内核，但功能有限，在我上一次看ipxe时，似乎还不支持菜单系统（不能通过配置文件实现菜单，要写代码、编译）。

​syslinux是一个bootloader，具有比较完善的bootloader的功能，例如做一些内存映射工作、支持多种类型的内核、chainload本地硬盘等。ipxe能加载内核文件其实属于不务正业。

​我不太清楚pxe/ipxe与syslinux的交互具体协议是怎样的。但是syslinux在自己实现http协议之前，网路通信都依赖于底层的pxe/ipxe提供支持，不过syslinux似乎并不关心url是什么协议，只是给pxe/ipxe一个url，pxe/ipxe想办法获取到内容再返回去，所以很老的pxelinux在ipxe之上也可以用http。

--

Cheng,

Best Regards

[Guo, Jiahua]

可以的。在 ipxe shell 中执行 config 命令，能看到一堆系统变量，包括主机的信息。网上的文档中应该也有描述。

另外，ipxe 可以使用 undi，也就是通用的网卡驱动，这是 pxe 协议的一部分（但似乎是可选的？不记得了……）。所以 ipxe 可以不依赖具体网卡驱动。

另外……
我见过一个软件包，可以用来干这事:
一 、启动一个 Linux 系统，作为 loader
二、在这个作为 loader 的 Linux 系统上通过 kexec 引导真正要启动的系统。

如果最终启动的系统只有 Linux，有什么方案灵活性比这个强么……