|
【老骥伏枥-原创】铁威马TOS 5.0的启动安装过程以及众测结果
前言 铁威马官方最近宣布了新版的TOS 5.0系统，开始让大家实施众测，我也来凑个热闹。帮助铁威马厂家测试一下这个新的系统。笔者测试的重点是“系统的启动安装过程”这个小小的环节，对该过程将做细致的系统性测试，并准备把该过程的详细测试报告写出来。在“那是云”论坛的“铁威马”板块上发表。对于希望了解TOS 5.0系统的朋友们，请仔细阅读每个测试章节的结论和结束语。如果你赞同本文的观点，可以回帖表是支持。如果你不赞同本文的观点，也可以回帖提出严肃的批判。“百花齐放，百家争鸣”，大家的目的都是为了帮助铁威马厂家的新产品更上一层楼。
【第一节】 测试前的准备以及必要的知识
以下是铁威马的官方论坛的介绍[1]：
如何安装 TOS 5 Beta？
- 下载 TOS 5 Beta 安装包：https://download2.terra-master.c ... 0071_2203221829.ins
- 登录您的 TOS，前往控制面板 > 通用设置 > 恢复出厂设置, 勾选 “恢复出厂设置” 并点击 “应用”， 以将您原先的系统清除；
- 您的 TNAS 将自动重启，并进入初始化安装指引页面；如果您无法进入初始化安装页面，请使用 TNAS PC 重新搜索您的 TNAS 的IP 地址，在浏览器地址栏中输入该 IP 地址进行访问；
- 安装过程请选择 “手动安装”模式，上传安装包，然后等待安装完成；
- 系统安装完成后，系统将自动重启；待系统重启后，按照页面指引完成管理员设置即可完成系统安装；
- 系统安装后，您需要清除浏览器缓存，否则部分系统页面有可能无法正确显示。
注意事项：
- Beta 版是程序的早期版本，包含大多数主要功能，但尚未完成，可能存在一些缺陷。此版本仅发布给部分特定人群或普通大众，以进行测试和收集反馈；
- Beta 版本不宜在工作或生产环境中使用，如果您的 TNAS 设备正在运行业务或者存储重要的资料，请勿参与本次测试；
- 由于TOS 5 的根文件系统、存储挂载路径、应用的存储位置与启动方式均与其他版本不同。您无法通过更新的方式来安装 TOS 5，而是需要重新安装系统。重新安装系统理论不会删除您硬盘上的数据，但为了安全起见，请务必提前备份您的数据；
- 本次发布的Beta 版本仅适用于TNAS 的 x.86 系列机型（220 系列、221 系列、420 系列、421 系列、422 系列）；
- 您当前的 TOS 系统版本要求不能低于 4.2.09；
- TOS 5 Beta 需要适配新版本的 TNAS PC (Windows OS:V5.0.4/macOS:V5.0.4) 和 TNAS Mobile (Android:V5.0.1/iOS:V5.0.1) 使用。
根据上述的铁威马官方指导，测试前的准备必须要下载 TOS 5 Beta 安装包。笔者下载的是：TOS_X642.0_5.0.58_Beta_00071_2203221829.ins 这个安装包。这是测试准备要做的第一步。
因为笔者要将测试的重点放在系统的启动安装过程，因此分析研究这个安装包中最基础的Linux内核是如何引导启动的，查找其中的Bug是测试的目的。还有就是内核启动后基于浏览器的管理又是如何进一步安装系统的，这个过程中有无Bug和安全漏洞，等等。根据笔者的测试经验，浏览器的管理是NAS的薄弱环节，Bug和漏洞常常会在这个环节中出现。进一步地测试会针对安装过程的环节。这个环节中的Bug也不容忽视，由于Bug引起的安装失败可能会导致硬件设备变成砖头，甚至需要返厂维修。
笔者准备将现有的TOS4.2.30版本，按照第二步的要求“前往控制面板 > 通用设置 > 恢复出厂设置, 勾选 “恢复出厂设置” 并点击 “应用”， 以将您原先的系统清除”去做。因为官方在注意事项中讲到“重新安装系统理论不会删除您硬盘上的数据，但为了安全起见，请务必提前备份您的数据”。为此笔者使用“Disk Cloning/Backup Tools for Linux”工具，可以直接恢复复原TOS4.2.30系统。
在做这一步之前，笔者认为有必要先介绍一下TOS4.2.30版本的启动基本知识。该版本是通过GUN GRUB 2.02 引导Linux内核实施启动过程的，现在处于“运行状态”的内核版本是4.19.165+。获取内核版本号的方法很简单，在TOS4.2.30运行起来以后，通过ssh登录到系统，执行：uname -r 命令即可得到内核版本。
GUN GRUB 2.02的启动描述在grub.cfg文件中，笔者现在的TOS4.2.30系统的启动描述内容如下：
menuentry "UTOS-X86-S64${uefi}" --id gnulinux {
insmod mdraid1x # load raid1 support for grub
if [ -e (md/UTOSCORE-X86-S64)/boot/bzImage ]; then
echo "----------------------------"
echo "- booting from RAID system -"
echo "----------------------------"
set root=(md/UTOSCORE-X86-S64)
linux /boot/bzImage type=raid
else
echo "----------------------------"
echo "- booting form INIT system -"
echo "----------------------------"
set root=(hd0, gpt1)
linux /boot/bzImage type=usb
fi
}
以上信息均为笔者的TOS4.2.30系统的公开信息。不存在任何超越权限获取信息的行为，这些必要知识只是为了在后续章节中讨论测试结果，评论测试系统的启动安装过程时，比较方便把问题描述清楚，更便于读者理解而已。
从上述的信息我们可以看到铁威马的Linux内核的启动过程仅仅执行这一个bzImage二进制文件，它会根据数据盘中是否已经设定了raid并安装了系统，而确定要执行“运行状态”或“安装状态”两种情况。通过“type=raid”或“type=usb”来告知内核。这就是铁威马内核的启动过程。
熟悉Linux系统的朋友们都知道，Linux内核启动一般由两个部分组成。内核的执行文件bzImage和初始文件系统initramfs。但铁威马内核只有一个文件，那么它的初始文件系统呢？答案很简单，铁威马厂家的设计是将初始文件系统绑定到执行文件bzImage之中了。Linux内核是容许这样构成系统的。这种做法有优点也有缺点，本文的目的是测试，不是分析铁威马内核启动设计的优缺点。对于超越本文范畴问题有兴趣的读者请自行上网查阅，这里就不做进一步讨论了。
笔者本次参加众测的重点是TOS5.0.58系统的启动和安装过程，根据上面介绍的必要知识，本文测试场景设计将主要针对“linux /boot/bzImage type=usb”这个过程中的各种情况。
后面的章节将针对每一种情况的测试场景作详细的测试报告。包括测试步骤设计，测试观察分析，测试结论，评论与建议，等等细节。对于本文的不妥之处敬请读者和铁威马厂家批评指正。
【第二节】 用TOS4.2.30系统做升级安装TOS5.0.58测试
测试步骤设计：按照官方的第二步的要求“前往控制面板 > 通用设置 > 恢复出厂设置, 勾选 “恢复出厂设置” 并点击 “应用”， 以将您原先的系统清除”，构建测试环境。通过Firefox浏览器安装TOS5.0.58系统。（当然还应当测试其他类型的浏览器，例如Chrome，Edge，IE等等。但这些不是笔者测试的重点，就暂时省略了。）
测试观察分析：启动刚刚构建的测试环境系统，观察系统内核启动信息。打开Firefox浏览器，输入IP地址（笔者为了方便测试，事先通过路由器的DHCP给硬件设备的MAC分配了固定的IP地址。今后提到“输入IP地址”，均为此种情况），发现浏览器出现了一个加载initboot的进度条，加载完成后进入初始化安装界面。此时笔者关闭浏览器，清除浏览器缓存，重新打开浏览器就再也不会出现加载initboot的进度条了。关闭系统内核重启，再次打开浏览器，又会出现加载initboot的进度条。
笔者分析认为，每次重启TOS4.2.30升级安装内核，都会出现加载initboot的进度条。由于笔者观测到这个测试的细节，于是笔者怀疑可能存在bug，需要进一步确认，因此笔者打开了前台浏览器的跟踪，分析为什么会只出现一次出现加载initboot的进度条，而不是每次都出现该加载。
测试结论：初次重启TOS4.2.30升级安装内核，在浏览器的跟踪记录中会发现如下信息：
filename "X64.tar"
version "V4.9.8"
hash "7bca30fa4947c2d83608f687783d1504"
url http://dl.terra-master.com/cn/PATCH/X64.tar
关闭浏览器再次启动浏览器，如果不重新启动TOS4.2.30升级安装内核，就不会再有这个跟踪记录了。
关于这个“X64.tar”是个什么东西，是笔者通过后来的测试才确认的。（在此提前给出一下，以便解说清楚笔者的测试过程。"X64.tar"这个文件其实是安装任何版本的TOS系统的Bootloader。）
笔者再次分析认为，如果不重新启动TOS4.2.30的升级安装内核，虽然只有初次打开浏览器会出现加载initboot的进度条这个现象可以确认它不是一个bug。甚至可以说是一个良好的启动设计。
但为了测试的严谨性，因为这个测试结论是笔者在“联网状态”下测试的结果，因此笔者还需要补充“断网状态”下的情况。（模拟服务器宕机条件下的安装）。于是笔者在家庭的路由器后面组成的局域网内，切断了与internet的联系，再次新启动TOS4.2.30升级安装内核，打开浏览器，输入IP地址，看看是否还能进入初始化安装界面。以后提到的“断网状态”，均是指在家庭局域网内，切断了与internet的联系的状态。
再次测试结论：在“断网状态”的情况下，启动TOS4.2.30升级安装内核，仍然可以进入初始化安装界面，正常安装TOS5.0.58系统。
评论与建议：笔者对此有些迷惑不解，用TOS4.2.30升级安装TOS5.0.58系统的过程中，联网下载“X64.tar”这个Bootloader文件其实并没有意义啊。既然“断网状态”不能下载它也可以正常安装？为什么要在“联网状态”下多此一举呢？这不是“脱了裤子放屁”吗？不知道铁威马为什么要这样做？在解开迷惑之前笔者不能置评这个问题。
【第三节】 对TOS5.0.58系统做恢复出厂设置测试
测试步骤设计：将已经安装好的TOS5.0.58系统清除“前往控制面板 > 系统 >出厂设置, 勾选 “恢复出厂设置” 并点击 “应用”， 清除系统”，构建TOS5.0.58的恢复出厂设置测试环境。通过Firefox浏览器重新安装TOS5.0.58系统。
根据【第二节】的测试经验，此次首先做“联网状态”情况的测试，然后再做“断网状态” 情况的测试。
联网状态的测试观察分析：启动刚刚构建的测试环境系统，观察系统内核启动信息。打开Firefox浏览器，输入IP地址，发现浏览器上出现了一个30秒倒计时提示从服务器加载Bootloader的画面，截屏如下：
加载完成后进入初始化安装界面。如果笔者关闭浏览器，清除浏览器缓存，重新打开浏览器就再也不会出现加上述面了。关闭系统内核重启，再次打开浏览器，初次加载又会出现上述。这与用TOS4.2.30系统做升级安装TOS5.0.58时的表现完全相同。只是告知用户要从服务器加载一个Bootloader。为了确认该Bootloader是否与TOS4.2.30版本的相同。笔者再次打开了前台浏览器的跟踪，查看此时从服务器下载的Bootloader version: 1.0.1 是什么？
测试结论：初次重启TOS5.0.58安装内核，在浏览器的跟踪记录中会发现如下信息：
filename "common_bootloader_V5.1.5.img"
hash "2681d9c63cc6c7e93597a939040907df"
url http://dl.terra-master.com/cn/PATCH/common_bootloader_V5.1.5.img
看来TOS5.0.58的Bootloader version: 1.0.1与TOS4.2.30的X64.tar升级安装使用的是不同的Bootloader。至少名称是不一样的，内容是否一样笔者不能确认。TOS4.2.30是X64.tar文件，TOS5.0.58是common_bootloader_V5.1.5.img文件。虽然bootloader不同，但两者的表现基本上是一致的，从浏览器的界面不同这一点来看，笔者猜想大概率两者的Bootloader内容是不同的。新版的Bootloader是否有bug或漏洞，还需要继续深入测试。
接下来再做“断网状态” 情况的测试。让我们看看测试的情况如何。
断网状态测试观察分析：为了保证测试的一致性，笔者重构了TOS5.0.58测试环境系统内核，观察系统内核启动信息。打开Firefox浏览器，输入IP地址，发现浏览器也还是出现了一个30秒倒计时的从服务器加载Bootloader的画面。但倒计时结束后表现出了不同于TOS4.2.30升级安装的情况。TOS5.0.58内核在“断网状态”情况下，不能进入初始化安装界面了。取而代之的是如下截图画面：
此时容许以用户手动方式加载Bootloader。笔者为了继续测试后续的情况，手动加载了common_bootloader_V5.1.5.img这个文件。测试顺利，可以成功进入初始化安装界面。
测试结论：TOS5.0.58内核“断网状态” 的表现与TOS4.2.30系统做升级安装不同。TOS5.0.58内核额外提供了这个容许用户手动加载Bootloader的界面。笔者在【第二节】的评论与建议中迷惑不解的问题，现在有了明确的答案。TOS5.0.58内核启动安装时，一定需要从服务器中获取Bootloader。如果无法获取，安装过程就不能继续完成。所以TOS5.0.58内核“断网状态”下需要提供用户手动加载Bootloader的界面。这也是Bootloader version: 1.0.1与Bootloader X64.tar的不同之处。同时笔者猜想，TOS4.2.30系统不提供这个功能肯定是它拥有内置预装的Bootloader。联网状态下实施“换装”或者叫“更新”，“断网状态”下就使用内置预装的Bootloader。这样就不需要提供户手动加载Bootloader的界面了。
根据笔者40年的计算机软硬件开发经验，认为对这个用户手动加载Bootloader的页面需要进一步的测试，查看它是否会带来安全上的漏洞。为此笔者又设计了如下的测试。
由于NASYUN的篇幅限制，请看楼下，【第四节】 【TOS5.0.58用户手动加载Bootloader页面的安全漏洞测试】，精彩继续！
|
淘帖
云币0
贡献47
活跃721
精华
