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

612 views
Skip to first unread message

崔灏 (CUI Hao)

unread,
Jun 18, 2014, 4:47:25 AM6/18/14
to LUG@USTC
以前的 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)

unread,
Jun 18, 2014, 4:55:55 AM6/18/14
to LUG@USTC
由于不清楚各个阶段的程序格式、工作方式(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

unread,
Jun 18, 2014, 5:06:05 AM6/18/14
to USTC LUG
​首先需要理清楚几个概念: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

unread,
Jun 18, 2014, 5:16:34 AM6/18/14
to USTC LUG
​关于版本,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

unread,
Jun 18, 2014, 5:28:55 AM6/18/14
to USTC LUG
关于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)

unread,
Jun 18, 2014, 6:53:05 AM6/18/14
to LUG@USTC
嗯,也就是说,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

unread,
Jun 19, 2014, 10:23:27 AM6/19/14
to USTC LUG

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

unread,
Jun 19, 2014, 12:28:18 PM6/19/14
to USTC_LUG
问个小白问题,为什么不能让 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

unread,
Jun 19, 2014, 12:39:52 PM6/19/14
to USTC LUG

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

unread,
Jun 19, 2014, 1:02:53 PM6/19/14
to USTC_LUG
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

unread,
Jun 19, 2014, 1:15:45 PM6/19/14
to USTC LUG
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

unread,
Jun 19, 2014, 1:24:14 PM6/19/14
to USTC_LUG
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

unread,
Jun 19, 2014, 1:27:02 PM6/19/14
to USTC_LUG
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

unread,
Jun 19, 2014, 1:27:03 PM6/19/14
to USTC LUG
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

unread,
Jun 19, 2014, 1:36:02 PM6/19/14
to USTC LUG

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

unread,
Jun 19, 2014, 2:12:51 PM6/19/14
to ustc...@googlegroups.com

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

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

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

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

Reply all
Reply to author
Forward
0 new messages