使用pxe安装ARM服务器(鲲鹏920)遇到的坑

一、关于PXE获取到IP之后无ACK，无法获取引导文件。

目前ARM服务器基本都是使用UEFI的方式进行引导，我们只需要关注EFI方式引导即可，Legacy引导已经随着时代的发展被扫进历史的垃圾桶。

正常情况下通过DHCP引导的PXE安装， DHCPdiscover -> DHCPoffer -> DHCPRequest -> DHCPACK，但是很奇怪的是在我们这个型号的服务器上始终没有发现有DHCP ACK的记录，这就意味着服务器无法获取到EFI引导文件。原来以为是我的dhcpd.conf配置写的不对，仔细核对了一翻发现没有问题，也在虚拟机测试了一下能正常引导。经过一翻搜索，发现原来是鲲鹏920的ARM服务器，在dhcpd的vendor-class-identifier 参数定义有特殊的字符串，下面给出本次实施中使用的dhcpd.conf的部分配置文件。

subnet 192.168.3.0 netmask 255.255.255.0
{
    range 192.168.3.10 192.168.3.239;
    option routers 192.168.3.3;
    next-server 192.168.3.3;

    class "HW-client" {
        match if substring
            (option vendor-class-identifier, 0, 9) =
            "HW-Client";
        if option architecture-type = 00:0b {
                # Huawei Kunpeng 920 ARM64 aarch64 EFI BIOS
                filename "images/BOOTAA64.EFI";
            }
    }

    class "pxeclients" {
        match if substring
            (option vendor-class-identifier, 0, 9) =
            "PXEClient";
        if option architecture-type = 00:07 or
            option architecture-type = 00:09 {
                # x86-64 EFI BIOS
                filename "images/shim.efi";
                # filename "images/BOOTX64.efi";
            } else if option architecture-type = 00:0b {
                # ARM64 aarch64 EFI BIOS
                filename "images/BOOTAA64.EFI";
            } else {
                # Legacy non-EFI BIOS
                filename "pxelinux.0";
            }
    }
}

为了兼顾多种平台的pxe引导需要，我们一般使用dhcpd.conf 中的class类功能进行不同cpu平台的区分，x86平台基本上默认vendor-class-identifier 标识符都是 PXEClient 这个字符串，而ARM的生态目前还远不如x86这样高度统一，这就造成了不同的厂商可能会对各自生产的平台进行自定义，对于鲲鹏920的平台，需要将 vendor-class-identifier 设为 HW-Client，见上面配置文件的标红部分，注意该标识符大小写必须完全一致。在修改了vendor-class-identifier之后，终于能正常获取efi引导文件。

从UEFI的规范文件中我们看到，arm平台和x86平台的efi引导文件是不一样的，如下图。

所以本次的实施中，我们需要从麒麟aarch64的安装ISO中，提取名为BOOTAA64.EFI以及grubaa64.efi，以引导至grub efi的bootloader界面进一步进行安装程序的后续引导。需要注意的是x86平台和arm64平台的efi文件都是不通用的。

二、关于clonezilla的arm64版本。

clonezilla目前的官方正式发布的版本里面，只有x86-64的iso，经过一番寻找，在官网找到了experimental 的实验性质的arm64的版本iso，下载地址为 http://free.nchc.org.tw/clonezilla-live/experimental/arm/20200414-focal/ ，这个是基于ubuntu 20.04 arm64的版本。实测可以正常用于引导本次实施中使用的鲲鹏920的TG225 B1服务器。

至于为什么要选择clonezilla用来自动配RAID，前序文章有提到，这里再写一下。其一是clonezilla的iso较小(约300M)引导较快；其二是它支持通过grub的引导参数来传递自定义参数，且支持的参数语法非常的灵活，诸如运行自定义脚本、挂载nfs此类都不在话下，如此一来引导之后调用raid卡的管理工具进行自动配raid的操作就不足为奇了。

 

三、关于Adaptec的RAID卡的配置工具。

前序文章中我们在上一次实施x86的批量装机，大多配的是LSI/BCM/AVAGO的RAID卡，使用storcli的命令行工具可以方便的进行RAID配置。Adaptec的RAID卡也有自家的命令行管理工具叫arcconf ，使用方法跟前序文章中提到的 storcli 基本只有参数语法的差别。下面分享一下本次实施中使用的arcconf的命令。

arcconf DELETE 1 ARRAY ALL noprompt
arcconf create 1 logicaldrive max 5 0 8 0 9 0 10 0 11 0 12 0 13 0 14 0 15 noprompt

大致解释一下这个参数的意思，delete 1是指对raid controller 1进行删除操作，删除对象是 array all 即所有raid组，noprompt是不提示直接删除。第二行的create 1 是指对raid controller 1 logicaldrive进行创建逻辑盘即raid组，max是指使用raid组的最大空间，5是指raid5，后面的0 8一直到0 15是指将哪些盘加入raid组中，这个盘号可以使用 arcconf list 1来获取。

四、关于麒麟V10进行pxe引导的一系列诡异问题及bug。

menuentry 'Install Kylin V10 @ ARM64 UEFI Manually' --class red --class gnu-linux --class gnu --class os {
    linux /images/kylin/vmlinuz ip=dhcp inst.repo=http://192.168.3.3/kylin console=tty0 video=VGA-1:640x480-32@60me
    # linux /images/kylin/vmlinuz rd.debug ip=dhcp inst.repo=nfs:192.168.3.3:/mnt/kylin/ console=tty0 video=VGA-1:640x480-32@60me
    initrd /images/kylin/initrd.img
}

menuentry 'Install Kylin V10 @ ARM64 UEFI Kickstart' --class red --class gnu-linuxefi --class gnu --class os {
    linux /images/kylin/vmlinuz ip=dhcp inst.ks=http://192.168.3.3/ks.cfg console=tty0 video=VGA-1:640x480-32@60me
    initrd /images/kylin/initrd.img
}

上面是我们在本次实施中最终成功引导的grub引导参数，供参考。

arm64的grub的内核和initrd行的关键字跟x86不一样，x86的efi方式引导的内核和initrd行的关键字分别是 linuxefi 和 initrdefi，不知道为何到了arm64中，又改回跟legacy模式引导一样 linux 和 initrd 了，实测如果跟x86平台一样在上述关键字后面加上efi的后缀，无法正常引导。

在正常获取了内核和initrd之后，就应该引导到安装界面了。但是在参考了kylinV10的安装光盘的grub配置文件，原来是没有 console=tty0 这个参数的。实测中发现如果不加这个参数，则会导致加载完内核和initrd之后一直就卡在光标闪烁的界面不动了无法进到安装界面，加了console的参数才正常。这个问题非常的诡异，使用光盘iso安装就不需要，而使用pxe就需要，怎么也说不过去。

在前序文章中，我们使用nfs方式来挂载rhel7的安装iso进行pxe安装。然而在本次的实施中，使用nfs挂载kylinV10的介质始终无法引导到安装界面，更为神奇的是在我们的dhcp server的虚拟机的日志中是能很明显的看到nfs的成功挂载安装介质目录的动作的。后续无奈只能使用http方式，这样便可以顺利引导到安装界面了。猜测可能是kylinV10的bug，在不指定版本的情况下默认应该是挂载的NFSv4，也可能是只支持v3吧。

在踩了上面3个坑之后，终于看到了久违的安装界面，但是问题又来了。在安装界面无法正常获取到安装介质的repo，这就直接导致了无法选择需要安装的包无法继续安装。后面在麒麟厂商技术支持的指导下，我们发现原来是到了这个安装界面之后，网卡没能正常获取到ip地址，这个肯定是kylinV10的bug了。要解决这个问题，在图形安装界面的网卡配置那里，把网卡关一下再开一下，正确获取到IP之后，安装源就能正常获取到了。然后我们就对第一台服务器通过手动的方式完成了安装，安装完成重启进系统之后，在/root目录下面，它生成了kickstart的cfg文件，可以用于后续其它机器的批量自动安装OS。

但是这里又出现了另外一个问题，如果到安装界面后不能正确dhcp获取到IP，那就意味着后面使用kickstart的批量安装时同样会由于无法获取到IP而造成自动安装失败。为了解决这个问题，厂商建议是使用新版的install.img来进行安装，由于我们的http的安装介质是直接用厂商提供的iso挂载的，如果要替换这个文件，还得把iso解压出来，费时费力。经过分析，由于是第一次获取不到IP，那么我们在kickstart的文件里面，在安装开始前手动跑一下dhclient 获取一下IP，最终发现这个方法是可行的。操作起来很简单，编辑ks的cfg文件，在文件最开始，加入如下三行即可。

%pre
/sbin/dhclient
%end

最后的最后，我们还发现，手动安装的kylinV10自动生成的kickstart文件，在分区的部分会生成一些带有小数大小的分区或LV，而安装程序在解析kickstart文件时，遇到带有小数时直接就报错无法继续安装。解决办法也很简单，直接编辑kickstart文件，在分区/LV配置部分，把小数点及后面的小数直接删掉。在这个地方也能出现这样明显的bug是我万万没想到的。