[PATCH compass-ci] doc: add doc of rootfs

5 Dec 2021

Signed-off-by: Yu Chuan <13186087857@163.com>
---
  doc/help/rootfs/README.md                     | 146 ++++++++++++++++++
  .../compass-ci-use-rootfs/cifs-nfs-hw.md      |  58 +++++++
  .../compass-ci-use-rootfs/cifs-nfs-qemu.md    | 108 +++++++++++++
  .../rootfs/compass-ci-use-rootfs/cifs-nfs.md  |   7 +
  .../rootfs/compass-ci-use-rootfs/container.md |  86 +++++++++++
  .../rootfs/compass-ci-use-rootfs/initramfs.md |  80 ++++++++++
  .../rootfs/compass-ci-use-rootfs/local.md     |  80 ++++++++++
  doc/help/rootfs/how-to-get-rootfs/README.md   |  35 +++++
  .../auto-generate-cifs-nfs.md                 |  97 ++++++++++++
  .../manual-generate-cifs-nfs-local.md         |  58 +++++++
  .../manual-generate-initramfs.md              |  39 +++++
  11 files changed, 794 insertions(+)
  create mode 100644 doc/help/rootfs/README.md
  create mode 100644 doc/help/rootfs/compass-ci-use-rootfs/cifs-nfs-hw.md
  create mode 100644 doc/help/rootfs/compass-ci-use-rootfs/cifs-nfs-qemu.md
  create mode 100644 doc/help/rootfs/compass-ci-use-rootfs/cifs-nfs.md
  create mode 100644 doc/help/rootfs/compass-ci-use-rootfs/container.md
  create mode 100644 doc/help/rootfs/compass-ci-use-rootfs/initramfs.md
  create mode 100644 doc/help/rootfs/compass-ci-use-rootfs/local.md
  create mode 100644 doc/help/rootfs/how-to-get-rootfs/README.md
  create mode 100644 doc/help/rootfs/how-to-get-rootfs/auto-generate-cifs-nfs.md
  create mode 100644 doc/help/rootfs/how-to-get-rootfs/manual-generate-cifs-nfs-local.md
  create mode 100644 doc/help/rootfs/how-to-get-rootfs/manual-generate-initramfs.md

diff --git a/doc/help/rootfs/README.md b/doc/help/rootfs/README.md
new file mode 100644
index 000000000000..eac1ea01ee58
--- /dev/null
+++ b/doc/help/rootfs/README.md
@@ -0,0 +1,146 @@
+[TOC]
+
+1 概念解释
+==========
+
+1.1 Compass-CI的rootfs是什么？
+------------------------------
+
+Compass-CI的rootfs是指存放在服务器端的，有版本的，可以为执行机在执行指定os,os_arch,os_version的job时提供相同的，干净的执行环境的docker镜像/文件/目录。
+
+Compass-CI当前可供测试的执行机类型有：docker, 虚拟机, 物理机。
+- 对docker而言，rootfs就是docker registry里面的指定版本的docker image。
+- 对虚拟机和物理机而言，rootfs就是在指定版本的iso安装完毕后，将其所有文件（运行时文件除外）拷贝出来，归档到/srv/os或/srv/initrd下版本对应的目录/文件。
+
+1.2 os_mount是什么？
+--------------------
+
+Compass-CI的job执行是通过submit命令来触发的，os_mount是submit时候的一个参数，用来指定本次job执行所需os是通过何种方式提供的。
+
+|----------------------------------|-------------------------------------------------------------------------------|
+| Compass-CI目前支持的os_mount类型 | 简单说明                                                                      |
+|----------------------------------|-------------------------------------------------------------------------------|
+| container                        | 对应执行环境为docker                                                          |
+| initramfs                        | 内存文件系统，系统所需文件一次性全部加载到内存中                              |
+| nfs                              | 内存文件系统，系统所需文件是通过nfs协议mount的，使用到多少文件，加载多少文件  |
+| cifs                             | 内存文件系统，系统所需文件是通过cifs协议mount的，使用到多少文件，加载多少文件 |
+| local                            | 硬盘文件系统，系统所需文件是位于一个指定名称格式的逻辑卷中                    |
+|----------------------------------|-------------------------------------------------------------------------------|
+
+1.3 rootfs与os_mount的关系是什么？
+----------------------------------
+
+job通过submit命令来提交到compass-ci调度器；
+
+submit job时候需要指定os_mount，若不指定，默认值如下：
+- 若指定本次执行机类型为docker，则os_mount默认为container；
+- 若指定本次执行机类型为虚拟机/物理机，则os_mount默认为initramfs；
+
+rootfs需要在sbumit job之前制作好，否则submit job会得到错误返回。
+
+|--------------|-----------------------------------------------------------------|
+| os_mount类型 | 对应的rootfs存储位置                                            |
+|--------------|-----------------------------------------------------------------|
+| container    | Compass-CI集群的docker registry。image格式：${os}:${os_version} |
+| initramfs    | /srv/initrd/osimage/${os}/${os_arch}/${os_version}/current      |
+| cifs/nfs     | /srv/os/${os}/${os_arch}/${os_version}                          |
+| local        | /srv/os/${os}/${os_arch}/${os_version}-iso                      |
+|--------------|-----------------------------------------------------------------|
+
+注：
+local与cifs/nfs现阶段的区别如下：
+- cifs/nfs所需的rootfs目前是通过安装iso到虚拟机得到的；
+- local所需的rootfs目前是通过安装iso到物理机得到的；
+- 理论上：
+  - 就与手动安装iso到物理机的系统差异而言，安装iso到物理机得到的rootfs，差异是小于安装iso到虚拟机得到的rootfs的；
+  - 所以，local能用的rootfs，是可以直接用于cifs/nfs的，而且以后如果安装iso到物理机得到rootfs的方式自动化完毕，那么在磁盘的/srv/os下，是只需要保留安装iso到物理机得到的rootfs的，现阶段local需要的-iso后缀可以去掉，cifs/nfs/local，都使用同一套rootfs。
+
+
+2 使用指南
+==========
+
+[提交job](../../job/submit/submit-job.zh.md)
+[os_mount](../../job/fields/os_mount.md)
+如何查看当前compass-ci集群支持的rootfs都有哪些？ # 待补充
+
+
+3 管理员手册
+============
+
+3.1 Compass-CI的rootfs是怎么来的？（原理）
+------------------------------------------
+
+### 3.1.1 container
+
+基于指定版本的基础镜像基础，制作docker image，并上传到docker registry中
+
+### 3.1.2 nfs/cifs
+
+- 安装iso到虚拟机的硬盘（qcow2）上；
+- 安装完成后，使用硬盘系统再进行一次启动/关机操作；
+- 将qcow2中的rootfs拷贝出来； # 可以使用compass-ci/container/qcow2rootfs容器进行拷贝
+- 对拷贝出来的rootfs进行一些post配置，即可用于compass-ci。
+
+> 详细post配置见之后的rootfs如何制作部分
+
+### 3.1.3 local
+
+- 安装iso到物理机的硬盘A上；
+- 安装完成后，使用硬盘A上的系统再进行一次启动/关机操作；
+- 使用非安装iso的硬盘A启动系统（可以使用内存文件系统，也可以使用其他硬盘上的系统），将硬盘A中的rootfs拷贝出来；
+- 对拷贝出来的rootfs进行一些post配置，即可用于compass-ci。
+
+> 详细post配置见之后的rootfs如何制作部分
+
+### 3.1.4 initramfs
+
+iniramfs所需的rootfs是一个包含了所有系统必须文件的cgz文件。
+所以我们使用cpio将cifs/nfs/local制作出来的rootfs打包制作成cgz文件即可。
+假设此rootfs位于B目录，将B目录整体打包。
+
+> 详细打包命令见之后的rootfs如何制作部分
+
+
+3.2 我已有Compass-CI集群，如何获得rootfs？
+------------------------------------------
+
+[3.2 我已有Compass-CI集群，如何获得rootfs？](./how-to-get-rootfs/README.md)
+
+
+3.3 我已有Compass-CI集群，已有rootfs，如何更新？
+------------------------------------------------
+
+### 3.3.1 更新os_mount=container的rootfs
+
+根据docker registry里的基线版本启动一个docker container，进行需要的更新后，覆盖提交到docker registry。
+
+### 3.3.2 更新os_mount=cifs/nfs/local的rootfs
+
+根据/srv/os/${os}/${os_arch}/${os_version}这个软链接指向的基线版本目录复制一个新的版本目录，在新版本目录中进行需要的更新后，将软链接指向新的版本。
+
+### 3.3.3 更新os_mount=initramfs的rootfs
+
+将/srv/initrd/osimage/${os}/${os_arch}/${os_version}/current这个软链接指向的基线版本cgz解压到一个临时目录，在临时版本目录中进行需要的更新后，将临时目录重新打包为新的版本，并将软链接指向新的版本。
+
+解压cgz命令参考：
+```
+unzip_dir="$(date "+%Y%m%d%H%M")-unzip"
+
+mkdir -p $unzip_dir && cd $unzip_dir
+zcat < $(realpath /srv/initrd/osimage/${os}/${os_arch}/${os_version}/current) | cpio -idmv
+```
+
+制作cgz命令参考：
+- 参考之前的手动制作initramfs rootfs步骤
+
+
+3.4 Compass-CI内部是如何使用rootfs的？
+--------------------------------------
+
+[3.4.1 os_mount=container的rootfs是如何使用起来的](./compass-ci-use-rootfs/container.md)
+
+[3.4.2 os_mount=cifs/nfs的rootfs是如何使用起来的](./compass-ci-use-rootfs/cifs-nfs.md)
+
+[3.4.3 os_mount=local的rootfs是如何使用起来的](./compass-ci-use-rootfs/local.md)
+
+[3.4.4 os_mount=initramfs的rootfs是如何使用起来的](./compass-ci-use-rootfs/initramfs.md)
diff --git a/doc/help/rootfs/compass-ci-use-rootfs/cifs-nfs-hw.md b/doc/help/rootfs/compass-ci-use-rootfs/cifs-nfs-hw.md
new file mode 100644
index 000000000000..9812bf439363
--- /dev/null
+++ b/doc/help/rootfs/compass-ci-use-rootfs/cifs-nfs-hw.md
@@ -0,0 +1,58 @@
+#### 3.4.2.2 物理机使用cifs/nfs的rootfs流程
+
+物理机类型的testbox需要设置物理机的首选启动项为PXE，它的运行是从上电启动开始的。
+
+所以我们分析rootfs如何使用，从上电开始分析。
+
+1. testbox启动并与调度器建立websocket连接，等待job
+
+- 物理机上电启动，进入到pxe阶段，pxe阶段会向同一网络发送pxe请求；
+
+- 这时Compass-CI集群提供的dnsmasq服务，会接收到这个pxe请求，返回给物理机一个可用的ipxe驱动下载地址； # 如：/tftpboot/ipxe/bin-arm64-efi/snp.efi
+
+- 物理机拿到并加载ipxe驱动，加载完成后会再次向同一网络发出ipxe请求；
+
+- 这时Compass-CI集群提供的dnsmasq服务，会接收到这个ipxe请求，返回给物理机一个tftp ipxe文件下载地址； # 如：boot.ipxe （此处为相对路径，即文件真实路径：/tftpboot/boot.ipxe）
+
+- 物理机拿到并执行ipxe命令行所组成的boot.ipxe。
+  - boot.ipxe内容如下：
+    ```
+    #!ipxe
+    set scheduler 172.168.131.113
+    set port 3000
+
+    chain http://${scheduler}:${port}/boot.ipxe/mac/${mac:hexhyp}
+
+    exit
+    ```
+  - 所以，到此步骤，物理机testbox已经与调度器建立了连接，等待job。
+
+    - 服务端（调度器）如果半个小时都没有调度到这个客户端的任务，就会给客户端返回如下返回值:
+      ```
+      chain http://#{ENV["SCHED_HOST"]}:#{ENV["SCHED_PORT"]}/boot.ipxe/mac/${mac:hexhyp}"
+      ```
+      - 物理机接收到此返回值，会继续请求job
+
+    - 服务端（调度器）如果找到了对应的job，会返回给客户端经过组合的返回值。（相当于客户端接收到了job）。
+      返回值举例：
+      ```
+      #!ipxe
+
+      initrd http://172.168.131.113:8000/os/openeuler/aarch64/20.03-2021-05-18-15-08-52/b...
+      initrd http://172.168.131.113:8000/os/openeuler/aarch64/20.03-2021-05-18-15-08-52/b...
+      initrd http://172.168.131.113:3000/job_initrd_tmpfs/crystal.3584856/job.cgz
+      initrd http://172.168.131.113:8800/upload-files/lkp-tests/aarch64/v2021.09.23.cgz
+      initrd http://172.168.131.113:8800/upload-files/lkp-tests/9f/9f87e65401d649095bacdf...
+      kernel http://172.168.131.113:8000/os/openeuler/aarch64/20.03-2021-05-18-15-08-52/b... user=lkp job=/lkp/scheduled/job.yaml ip=dhcp rootovl ro root=cifs://172.168.131.113/os/openeuler/aarch64/20.03-2021-05-18-15-08-52,guest,ro,hard,vers=1.0,noacl,nouser_xattr,noserverino  initrd=initramfs.lkp-4.19.90-2003.4.0.0036.oe1.aarch64.img  initrd=modules-4.19.90-2003.4.0.0036.oe1.aarch64.cgz  initrd=job.cgz  initrd=v2021.09.23.cgz  initrd=9f87e65401d649095bacdff019d378e6.cgz rootfs_disk=/dev/vdb crashkernel=auto
+      boot
+      ```
+
+2. testbox（客户端）接收到job，开始准备环境，执行job
+
+- 客户端解析并执行服务端（调度器）传回来的返回值，开始启动
+
+  - 服务端传回来的返回值，直接是由ipxe命令组成的字符串，所以，这个字符串会被ipxe直接解析执行
+  - 如上面的例子，这个字符串的最后一行是“boot”，所以，物理机此时，会进入Compass-CI自定义化的Linux开机流程。
+
+- Compass-CI的自定义化的linux开机流程
+  由于都是os_mount=cifs/nfs，所以，物理机的开机流程与3.4.2.1的“虚拟机使用cifs/nfs的rootfs流程”部分的开机流程一致。
diff --git a/doc/help/rootfs/compass-ci-use-rootfs/cifs-nfs-qemu.md b/doc/help/rootfs/compass-ci-use-rootfs/cifs-nfs-qemu.md
new file mode 100644
index 000000000000..4195f5ab2a4a
--- /dev/null
+++ b/doc/help/rootfs/compass-ci-use-rootfs/cifs-nfs-qemu.md
@@ -0,0 +1,108 @@
+#### 3.4.2.1 虚拟机使用cifs/nfs的rootfs流程
+
+虚拟机类型的testbox是通过调用/c/compass-ci/providers/qemu.sh脚本，同时给其传入各种运行时参数，运行起来的。
+
+所以我们分析rootfs如何使用，从这个脚本开始分析。
+
+1. testbox启动并与调度器建立websocket连接，等待job
+
+- /c/compass-ci/providers/qemu.sh
+  - functions:
+    main()
+  - key code:
+    source "$CCI_SRC/providers/$provider/${template}.sh"
+
+- /c/compass-ci/providers/qemu/kvm.sh
+  - functions:
+    write_logfile()
+  - key code:
+    ```bash
+    url=ws://${SCHED_HOST:-172.17.0.1}:${SCHED_PORT:-3000}/ws/boot.ipxe/mac/${mac}
+    ipxe_script_path="$(pwd)/${ipxe_script}"
+    command -v ruby &&
+            ruby -r "${CCI_SRC}/providers/lib/common.rb" -e "ws_boot '$url','$hostname','$index','$ipxe_script_path'"
+    ```
+  - 说明：
+    - ws_boot()是位于/c/compass-ci/providers/lib/common.rb中的，compass-ci封装的一个方法;
+    - ws_boot()运行的一侧，属于客户端，它会与服务端（调度器）建立websocket长链接，请求job；
+    - 服务端（调度器）如果半个小时都没有调度到这个客户端的任务，就会给客户端返回包含“no job now”的返回值；
+      /c/compass-ci/providers/qemu/kvm.sh中会处理返回值：
+      - 如果返回值包含“no job now”，那么继续循环请求job；
+    - 服务端（调度器）如果找到了对应的job，会返回给客户端经过组合的返回值。（相当于客户端接收到了job）。
+      返回值举例：
+      ```
+      #!ipxe
+
+      initrd http://172.168.131.113:8000/os/openeuler/aarch64/20.03-2021-05-18-15-08-52/b...
+      initrd http://172.168.131.113:8000/os/openeuler/aarch64/20.03-2021-05-18-15-08-52/b...
+      initrd http://172.168.131.113:3000/job_initrd_tmpfs/crystal.3584856/job.cgz
+      initrd http://172.168.131.113:8800/upload-files/lkp-tests/aarch64/v2021.09.23.cgz
+      initrd http://172.168.131.113:8800/upload-files/lkp-tests/9f/9f87e65401d649095bacdf...
+      kernel http://172.168.131.113:8000/os/openeuler/aarch64/20.03-2021-05-18-15-08-52/b... user=lkp job=/lkp/scheduled/job.yaml ip=dhcp rootovl ro root=cifs://172.168.131.113/os/openeuler/aarch64/20.03-2021-05-18-15-08-52,guest,ro,hard,vers=1.0,noacl,nouser_xattr,noserverino  initrd=initramfs.lkp-4.19.90-2003.4.0.0036.oe1.aarch64.img  initrd=modules-4.19.90-2003.4.0.0036.oe1.aarch64.cgz  initrd=job.cgz  initrd=v2021.09.23.cgz  initrd=9f87e65401d649095bacdff019d378e6.cgz rootfs_disk=/dev/vdb crashkernel=auto
+      boot
+      ```
+
+2. testbox（客户端）接收到job，开始准备环境，执行job
+
+- /c/compass-ci/providers/qemu/kvm.sh
+  - functions:
+    write_logfile() > parse_ipxe_script() > run_qemu()
+  - key code:
+    ```bash
+    ###################
+    # func: parse_ipxe_script()
+    #       - 解析调度器传回来的返回中的kernel那一行
+    #       - kernel那一行举例: kernel http://172.168.131.113:8000/os/openeuler/aarch64/20.03-2021-05-18-15-08-52/b... user=lkp job=/lkp/scheduled/job.yaml ip=dhcp rootovl ro root=cifs://172.168.131.113/os/openeuler/aarch64/20.03-2021-05-18-15-08-52,guest,ro,hard,vers=1.0,noacl,nouser_xattr,noserverino  initrd=initramfs.lkp-4.19.90-2003.4.0.0036.oe1.aarch64.img  initrd=modules-4.19.90-2003.4.0.0036.oe1.aarch64.cgz  initrd=job.cgz  initrd=v2021.09.23.cgz  initrd=9f87e65401d649095bacdff019d378e6.cgz rootfs_disk=/dev/vdb crashkernel=auto
+    ###################
+
+    kernel)
+            kernel=$(basename "$b")
+            wget --timestamping -nv -a ${log_file} $b
+            append=$(echo "$c" | sed -r "s/ initrd=[^ ]+//g")
+            ;;
+
+    ###################
+    # func: run_qemu()
+    #       - 使用一些参数启动qemu
+    #       - ${append}是从上面解析得来的,请注意上面例子中kernel后面的3个关键字段：
+    #         - overlay
+    #         - initrd=initramfs.lkp-5.3.18-57-default.img
+    #         - root=cifs://172.168.131.113/os/openeuler/aarch64/20.03-2021-05-18-15-08-52,guest,ro,hard,vers=1.0,noacl,nouser_xattr,noserverino
+    ###################
+
+    "${kvm[@]}" "${arch_option[@]}" --append "${append}"
+    ```
+  - 说明：
+    - 到此步，我们已经知道了，qemu是通过命令调用起来的，本次job所需的kernel, initrd(s), rootfs均以参数的形式传给了这个命令。
+    - 接下来，就到了Compass-CI的自定义化的linux开机启动流程。
+
+- Compass-CI的自定义化的linux开机流程
+
+  - Linux开机流程简要说明：
+    - 开机启动内核，内核加载initrd(s)中的所有文件到内存； # initrd(s)所有文件组合起来，会是一个文件系统
+    - 在内存中依次执行initrd(s)组成的系统中定义的启动项；
+    - 在执行这些启动项的时候，会根据传入的内核命令行参数（也就是${append}），来找到并启动本次要真正使用的文件系统。 # 这一步骤，依然还是在initrd(s)组成的文件系统中
+    - 启动本次真正要使用的文件系统。 # 这就是所谓的“切根” —— 使用的根文件系统，从initrd(s)组成的文件系统，“切”到真正要使用的文件系统
+
+  - 对cifs/nfs类型的job：
+    - 它真正要使用的文件系统，就是root=cifs://172.168.131.113/os/openeuler/aarch64/20.03-2021-05-18-15-08-52,guest,ro,hard,vers=1.0,noacl,nouser_xattr,noserverino
+
+    - 我们传入的initrd(s)组成的文件系统，包括了当前这台testbox执行分配给它的job所需要的文件； # 如lkp.cgz，job.cgz中的文件
+    - 但是这些文件是在initrd(s)组成的文件系统中的，而不在本次要真正使用的文件系统中；
+      - 相当于在initrd(s)组成的文件系统（/目录）中，有我们job需要的文件的；
+      - 而本次要真正使用的文件系统（/sysroot目录）中，没有我们job需要的文件的； # root=cifs://xxxx会通过指定的协议（cifs/nfs）挂载到/sysroot目录
+
+    - 所以，我们需要把job需要的文件从/目录，拷贝到/sysroot目录。
+    - 这个拷贝的动作，是由initrd(s)中的某一个开机启动项来触发的。
+
+    - 在cifs/nfs类型的job，由于我们传入的内核命令行参数中有overlay这个关键字，而overlay这个关键字，对应的有其开机启动项，拷贝的动作就是在这个开机启动项触发的。
+    - overlay对应的开机启动项，在默认的initrd中是不支持的，所以我们每做出一个rootfs，都需要通过/c/compass-ci/container/dracut-initrd这个容器来生成一个initrd。
+    - 在本例中，就是initrd=initramfs.lkp-5.3.18-57-default.img
+    - 而cifs/nfs类型的job，这个拷贝的动作对应的代码，位于：/c/compass-ci/container/dracut-initrd/bin/overlay-lkp.sh
+
+    - 拷贝前：root=cifs://xxxx已经通过指定的协议（cifs/nfs）挂载到/sysroot目录了
+    - 拷贝中：job所需要的文件会被拷贝到job真正要使用的文件系统（/sysroot）中
+    - 拷贝后：/sysroot是本次要真正使用的文件系统，接下来就是来启动/sysroot中的文件系统。
+
+    - 在这个系统中，已经有我们执行lkp所定义的任务所需要的一系列文件。其中就包括一个关键的系统服务：lkp-bootstrap.service。
+    - 所以，在/sysroot中的文件系统执行它自己的开机启动流程时，就能通过lkp-bootstrap.service，来执行我们定义好的job。
diff --git a/doc/help/rootfs/compass-ci-use-rootfs/cifs-nfs.md b/doc/help/rootfs/compass-ci-use-rootfs/cifs-nfs.md
new file mode 100644
index 000000000000..dbfe10f6e9ae
--- /dev/null
+++ b/doc/help/rootfs/compass-ci-use-rootfs/cifs-nfs.md
@@ -0,0 +1,7 @@
+### 3.4.2 os_mount=cifs/nfs的rootfs是如何使用起来的
+
+os_mount=cifs/nfs的rootfs会被虚拟机/物理机类型的testbox使用，虚拟机与物理机类型的testbox的启动方式不同，所以分开来讲。
+
+[3.4.2.1 虚拟机使用cifs/nfs的rootfs流程](./cifs-nfs-qemu.md)
+
+[3.4.2.2 物理机使用cifs/nfs的rootfs流程](./cifs-nfs-hw.md)
diff --git a/doc/help/rootfs/compass-ci-use-rootfs/container.md b/doc/help/rootfs/compass-ci-use-rootfs/container.md
new file mode 100644
index 000000000000..31f961f9fdba
--- /dev/null
+++ b/doc/help/rootfs/compass-ci-use-rootfs/container.md
@@ -0,0 +1,86 @@
+### 3.4.1 os_mount=container的rootfs是如何使用起来的
+
+os_mount=container的rootfs会被docker类型的testbox使用，docker类型的testbox是通过调用/c/compass-ci/providers/docker.rb脚本，同时给其传入各种运行时参数，运行起来的。
+
+所以我们分析rootfs如何使用，从这个脚本开始分析。
+
+1. testbox启动并与调度器建立websocket连接，等待job
+
+- /c/compass-ci/providers/docker.rb
+  - key code:
+    ```ruby
+    require_relative './docker/docker'
+    main(ENV['hostname'], ENV['queues'], ENV['uuid'], ENV['index'])
+    ```
+
+- /c/compass-ci/providers/docker/docker.rb
+  - functions:
+    main() > parse_response()
+  - key code:
+    ```ruby
+    require_relative '../lib/common'
+    ...omit...
+    response = ws_boot(url, hostname, index)
+    ```
+  - 说明：
+    - ws_boot()是位于/c/compass-ci/providers/lib/common.rb中的，compass-ci封装的一个方法;
+    - ws_boot()运行的一侧，属于客户端，它会与服务端（调度器）建立websocket长链接，请求job；
+    - 服务端（调度器）如果半个小时都没有调度到这个客户端的任务，就会给客户端返回包含“no job now”的返回值；
+      /c/compass-ci/providers/docker/docker.rb中会处理返回值：
+      - 如果返回值包含“no job now”，那么继续循环请求job；
+    - 服务端（调度器）如果找到了对应的job，会返回给客户端经过组合的返回值。（相当于客户端接收到了job）。
+      返回值举例：
+      ```
+      {"job_id"=>"crystal.3583794", "docker_image"=>"centos:7", "initrds"=>"[\"http://172.168.131.113:3000/job_initrd_tmpfs/crystal.3583794/job.cgz\",\"http://172.168.131.113:8800/upload-files/lkp-tests/aarch64/v2021.09.23.cgz\",\"http://172.168.131.113:8800/upload-files/lkp-tests/9f/9f87e65401d649095bacdff019d378e6.cgz\"]"}
+      ```
+
+2. testbox（客户端）接收到job，开始准备环境，执行job
+
+- /c/compass-ci/providers/docker/docker.rb
+  - functions:
+    parse_response() > start_container()
+  - key code:
+    ```ruby
+    ###################
+    # hash: 是服务端返回值解析而来的字典
+    #       - 如上例: "docker_image"=>"centos:7"
+    ###################
+
+    docker_image = hash['docker_image']
+    system "#{ENV['CCI_SRC']}/sbin/docker-pull #{docker_image}"
+    ```
+
+- /c/compass-ci/sbin/docker-pull
+  - functions:
+    main() > local_repository()
+  - key code:
+    ```bash
+    docker pull $DOCKER_REGISTRY_HOST:$DOCKER_REGISTRY_PORT/$image_name 2> /dev/null
+    ```
+  - 说明：
+    - 到此步，Compass-CI集群的docker registry里面的os_mount=container的rootfs（docker iamge），就被pull到执行机本地了。
+
+- /c/compass-ci/providers/docker/docker.rb
+  - functions:
+    start_container()
+  - key code:
+    ```ruby
+    system(
+        { 'job_id' => hash['job_id'],
+          'hostname' => hostname,
+          'docker_image' => docker_image,
+          'load_path' => load_path,
+          'log_dir' => "#{LOG_DIR}/#{hostname}" },
+        ENV['CCI_SRC'] + '/providers/docker/run.sh'
+      )
+    ```
+
+- /c/compass-ci/providers/docker/run.sh
+  - key code:
+    ```bash
+    docker run
+        ...omit...
+        ${docker_image}
+    ```
+  - 说明：
+    - 到此步，Compass-CI集群的docker registry里面的os_mount=container的rootfs（docker iamge），就被使用起来了。
diff --git a/doc/help/rootfs/compass-ci-use-rootfs/initramfs.md b/doc/help/rootfs/compass-ci-use-rootfs/initramfs.md
new file mode 100644
index 000000000000..6b917738565f
--- /dev/null
+++ b/doc/help/rootfs/compass-ci-use-rootfs/initramfs.md
@@ -0,0 +1,80 @@
+### 3.4.4 os_mount=initramfs的rootfs是如何使用起来的
+
+#### 3.4.4.1 虚拟机使用initramfs的rootfs流程
+
+虚拟机使用initramfs的rootfs流程与3.4.2.1的“虚拟机使用cifs/nfs的rootfs流程”大致相同，我们这里只说不同点。
+
+- 不同点1：调度器的返回值不同
+  - cifs/nfs返回值举例：
+    ```
+    #!ipxe
+
+    initrd http://172.168.131.113:8000/os/openeuler/aarch64/20.03-2021-05-18-15-08-52/b...
+    initrd http://172.168.131.113:8000/os/openeuler/aarch64/20.03-2021-05-18-15-08-52/b...
+    initrd http://172.168.131.113:3000/job_initrd_tmpfs/crystal.3584856/job.cgz
+    initrd http://172.168.131.113:8800/upload-files/lkp-tests/aarch64/v2021.09.23.cgz
+    initrd http://172.168.131.113:8800/upload-files/lkp-tests/9f/9f87e65401d649095bacdf...
+    kernel http://172.168.131.113:8000/os/openeuler/aarch64/20.03-2021-05-18-15-08-52/b... user=lkp job=/lkp/scheduled/job.yaml ip=dhcp rootovl ro root=cifs://172.168.131.113/os/openeuler/aarch64/20.03-2021-05-18-15-08-52,guest,ro,hard,vers=1.0,noacl,nouser_xattr,noserverino  initrd=initramfs.lkp-4.19.90-2003.4.0.0036.oe1.aarch64.img  initrd=modules-4.19.90-2003.4.0.0036.oe1.aarch64.cgz  initrd=job.cgz  initrd=v2021.09.23.cgz  initrd=9f87e65401d649095bacdff019d378e6.cgz rootfs_disk=/dev/vdb crashkernel=auto
+    boot
+    ```
+  - initramfs返回值举例：
+    ```
+    #!ipxe
+
+    initrd http://172.168.131.113:8800/initrd/osimage/openeuler/aarch64/20.03/20210609....
+    initrd http://172.168.131.113:8000/os/openeuler/aarch64/20.03-2021-05-18-15-08-52/b...
+    initrd http://172.168.131.113:8800/initrd/deps/initramfs/debian/aarch64/sid/run-ipc...
+    initrd http://172.168.131.113:8800/initrd/deps/initramfs/openeuler/aarch64/20.03/lk...
+    initrd http://172.168.131.113:3000/job_initrd_tmpfs/crystal.3585813/job.cgz
+    initrd http://172.168.131.113:8800/upload-files/lkp-tests/aarch64/v2021.09.23.cgz
+    initrd http://172.168.131.113:8800/upload-files/lkp-tests/9f/9f87e65401d649095bacdf...
+    kernel http://172.168.131.113:8000/os/openeuler/aarch64/20.03-2021-05-18-15-08-52/b... user=lkp job=/lkp/scheduled/job.yaml ip=dhcp rootovl ro rdinit=/sbin/init prompt_ramdisk=0  initrd=20210609.0.cgz  initrd=modules-4.19.90-2003.4.0.0036.oe1.aarch64.cgz  initrd=run-ipconfig_20201103.cgz  initrd=job.cgz  initrd=v2021.09.23.cgz  initrd=9f87e65401d649095bacdff019d378e6.cgz rootfs_disk=/dev/vdb crashkernel=auto
+    boot
+    ```
+  - 分析：
+    两种os_mount的不同，核心在于传递给kernel的命令行参数不同，而这个不同，会反映在不同点2：Compass-CI的自定义化的Linux启动流程不同
+
+- 不同点2：内核命令行参数不同，导致Compass-CI的自定义化的Linux启动流程不同
+
+  - os_mount=initramfs的系统，会直接使用在内存中解开的initrd(s)启动的系统，没有“切根”步骤
+    - initramfs的系统开机流程简要说明：
+      - 开机启动内核，内核加载initrd(s)中的所有文件到内存； # initrd(s)所有文件组合起来，会是一个文件系统
+      - 在内存中依次执行initrd(s)组成的系统中定义的启动项； # 所以，os_mount=initramfs，它的job的运行环境，是在内存中的一个文件系统。
+
+  - cifs/nfs与local的内核命令行参数相同项：
+    - user=lkp
+    - job=/lkp/scheduled/job.yaml
+    - ip=dhcp
+    - initrd=modules-4.19.90-2003.4.0.0036.oe1.aarch64.cgz
+    - initrd=job.cgz
+    - initrd=v2021.09.23.cgz
+    - initrd=9f87e65401d649095bacdff019d378e6.cgz
+    - rootfs_disk=/dev/vdb
+    - crashkernel=auto
+    - rootovl
+    - ro
+
+  - cifs/nfs的独立参数项：
+    - initrd=initramfs.lkp-4.19.90-2003.4.0.0036.oe1.aarch64.img
+      - 这个initrd文件是我们通过/c/compass-ci/container/dracut-initrd容器制作出来的，它包含一个最小化的文件系统，这个文件系统，是debian的。
+      - 但是os_mount=initramfs，由于没有切根的动作，所以它不能有debian系统的文件，它需要的是我们本次job真正要使用的文件系统。
+
+    - root=cifs://172.168.131.113/os/openeuler/aarch64/20.03-2021-05-18-15-08-52,guest,ro,hard,vers=1.0,noacl,nouser_xattr,noserverino # root设备使用cifsroot/nfsroot，它会调用95cifs/95nfs这个启动项。
+    - 说明：
+      - 从数字上95cifs/95nfs，会先于90overlay-root执行。
+      - 所以，在initrd(s)的系统启动阶段，会先执行95cifs/95nfs，挂载远程的cifs/nfs服务端的rootfs到/sysroot；
+      - 然后执行90overlay-root，会基于/sysroot，再覆盖一层可读写的overlayfs，并将job所需的文件拷贝到这层overlayfs中；
+      - 然后将这层可读写的overlayfs作为本次要使用的文件系统，并启动它，开始执行job。
+
+  - initramfs的独立参数项：
+    - rdinit=/sbin/init                 # 指定initrd(s)组成的文件系统中，要运行的1号进程
+    - prompt_ramdisk=0                  # 如上面我们讲的，os_mount=initramfs对应的文件系统是内存文件系统，所以需要这个参数，来让内核支持内存文件系统
+    - initrd=run-ipconfig_20201103.cgz  # 内存文件系统需要initramfs-tools来支持一些功能，比如支持rd.init，支持ipconfig配置ip等... （详情参考：https://manpages.ubuntu.com/manpages/xenial/man8/initramfs-tools.8.html）
+    - initrd=20210609.0.cgz             # 这个文件是os_mount=initramfs所对应的rootfs，它里面是本次job所指定的${os},${os_arch},${os_version}的所有文件
+
+    - 说明：
+      - os_mount=initramfs没有切根动作，initrd(s)组成的系统直接就是job的执行环境。
+
+#### 3.4.4.2 物理机使用initramfs的rootfs流程
+
+物理机使用initramfs的rootfs流程与[3.4.2.2 物理机使用cifs/nfs的rootfs流程](./cifs-nfs-hw.md)大致相同，不同点见上面的“3.4.4.1 虚拟机使用initramfs的rootfs流程”部分的两个不同点。
diff --git a/doc/help/rootfs/compass-ci-use-rootfs/local.md b/doc/help/rootfs/compass-ci-use-rootfs/local.md
new file mode 100644
index 000000000000..3d974ea3c9af
--- /dev/null
+++ b/doc/help/rootfs/compass-ci-use-rootfs/local.md
@@ -0,0 +1,80 @@
+### 3.4.3 os_mount=local的rootfs是如何使用起来的
+
+os_mount=local的rootfs会被虚拟机/物理机类型的testbox使用，虚拟机与物理机类型的testbox的启动方式不同，所以分开来讲。
+
+#### 3.4.3.1 虚拟机使用local的rootfs流程
+
+虚拟机使用local的rootfs流程与3.4.2.1的“虚拟机使用cifs/nfs的rootfs流程”大致相同，我们这里只说不同点。
+
+- 不同点1：调度器的返回值不同
+  - cifs/nfs返回值举例：
+    ```
+    #!ipxe
+
+    initrd http://172.168.131.113:8000/os/openeuler/aarch64/20.03-2021-05-18-15-08-52/b...
+    initrd http://172.168.131.113:8000/os/openeuler/aarch64/20.03-2021-05-18-15-08-52/b...
+    initrd http://172.168.131.113:3000/job_initrd_tmpfs/crystal.3584856/job.cgz
+    initrd http://172.168.131.113:8800/upload-files/lkp-tests/aarch64/v2021.09.23.cgz
+    initrd http://172.168.131.113:8800/upload-files/lkp-tests/9f/9f87e65401d649095bacdf...
+    kernel http://172.168.131.113:8000/os/openeuler/aarch64/20.03-2021-05-18-15-08-52/b... user=lkp job=/lkp/scheduled/job.yaml ip=dhcp rootovl ro root=cifs://172.168.131.113/os/openeuler/aarch64/20.03-2021-05-18-15-08-52,guest,ro,hard,vers=1.0,noacl,nouser_xattr,noserverino  initrd=initramfs.lkp-4.19.90-2003.4.0.0036.oe1.aarch64.img  initrd=modules-4.19.90-2003.4.0.0036.oe1.aarch64.cgz  initrd=job.cgz  initrd=v2021.09.23.cgz  initrd=9f87e65401d649095bacdff019d378e6.cgz rootfs_disk=/dev/vdb crashkernel=auto
+    boot
+    ```
+  - local返回值举例：
+    ```
+    #!ipxe
+
+    initrd http://172.168.131.113:8000/os/openeuler/aarch64/20.03-iso-2021-08-24-18-01-...
+    initrd http://172.168.131.113:8000/os/openeuler/aarch64/20.03-iso-2021-08-24-18-01-...
+    initrd http://172.168.131.113:3000/job_initrd_tmpfs/crystal.3584978/job.cgz
+    initrd http://172.168.131.113:8800/upload-files/lkp-tests/aarch64/v2021.09.23.cgz
+    initrd http://172.168.131.113:8800/upload-files/lkp-tests/9f/9f87e65401d649095bacdf...
+    kernel http://172.168.131.113:8000/os/openeuler/aarch64/20.03-iso-2021-08-24-18-01-... user=lkp job=/lkp/scheduled/job.yaml ip=dhcp local use_root_partition= save_root_partition= os_version=20.03-iso os_lv_size=10G os_partition= rw root=172.168.131.113:/os/openeuler/aarch64/20.03-iso-2021-08-24-18-01-07  initrd=initramfs.lkp-4.19.90-2003.4.0.0036.oe1.aarch64.img  initrd=modules-4.19.90-2003.4.0.0036.oe1.aarch64.cgz  initrd=job.cgz  initrd=v2021.09.23.cgz  initrd=9f87e65401d649095bacdff019d378e6.cgz rootfs_disk=/dev/vdb crashkernel=auto
+    boot
+    ```
+  - 分析：
+    两种os_mount的不同，核心在于传递给kernel的命令行参数不同，而这个不同，会反映在不同点2：Compass-CI的自定义化的Linux启动流程不同
+
+- 不同点2：内核命令行参数不同，导致Compass-CI的自定义化的Linux启动流程不同
+  - cifs/nfs与local的内核命令行参数相同项：
+    - user=lkp
+    - job=/lkp/scheduled/job.yaml
+    - ip=dhcp
+    - initrd=initramfs.lkp-4.19.90-2003.4.0.0036.oe1.aarch64.img
+    - initrd=modules-4.19.90-2003.4.0.0036.oe1.aarch64.cgz
+    - initrd=job.cgz
+    - initrd=v2021.09.23.cgz
+    - initrd=9f87e65401d649095bacdff019d378e6.cgz
+    - rootfs_disk=/dev/vdb
+    - crashkernel=auto
+
+  - cifs/nfs的独立参数项：
+    - rootovl	# 这个参数项会让dracut的90overlay-root，这一开机启动项执行
+    - ro      # root设备以只读模式挂载，因为有了rootovl，所以我们job对于系统所有的操作，都是在overlay的upper层进行的，并不会影响远程挂载的nfs/cifs服务端的文件
+    - root=cifs://172.168.131.113/os/openeuler/aarch64/20.03-2021-05-18-15-08-52,guest,ro,hard,vers=1.0,noacl,nouser_xattr,noserverino # root设备使用cifsroot/nfsroot，它会调用95cifs/95nfs这个启动项。
+    - 说明：
+      - 从数字上95cifs/95nfs，会先于90overlay-root执行。
+      - 所以，在initrd(s)的系统启动阶段，会先执行95cifs/95nfs，挂载远程的cifs/nfs服务端的rootfs到/sysroot；
+      - 然后执行90overlay-root，会基于/sysroot，再覆盖一层可读写的overlayfs，并将job所需的文件拷贝到这层overlayfs中；
+      - 然后将这层可读写的overlayfs作为本次要使用的文件系统，并启动它，开始执行job。
+
+  - local的独立参数项：
+    - local                # 这个参数项是我们自定义的 ，它会让我们给initrd(s)的系统中自定义的的开机启动项90lkp被调用
+    - use_root_partition=  # 这个参数项是我们自定义的 ，它会被90lkp捕获并解析使用
+    - save_root_partition= # 这个参数项是我们自定义的 ，它会被90lkp捕获并解析使用
+    - os_version=20.03-iso # 这个参数项是我们自定义的 ，它会被90lkp捕获并解析使用
+    - os_lv_size=10G       # 这个参数项是我们自定义的 ，它会被90lkp捕获并解析使用
+    - os_partition=        # 这个参数项是我们自定义的 ，它会被90lkp捕获并解析使用
+    - rw                   # root设备以读写模式挂载，这个参数只会在高级用户需要自定义ipxe命令行，且指定的root设备直接是某一块需要可读写的块设备时用到
+    - root=172.168.131.113:/os/openeuler/aarch64/20.03-iso-2021-08-24-18-01-07 # 这个是固定的，一方面会执行95nfs，另一方面，在之后的90lkp也会用到它
+    - 说明：
+      - 关于90lkp，请见：/c/compass-ci/container/dracut-initrd/modules.d/90lkp
+      - 从数字上95nfs，会先于90lkp执行。
+      - 所以，在initrd(s)的系统启动阶段，会先执行95nfs，挂载远程的nfs服务端的rootfs到/sysroot（实际上并不会用到它）；
+      - 然后执行90lkp，会根据传入的内核命令行参数（包括root），来将root对应的rootfs拷贝到指定格式的lv中； # 详见：/c/compass-ci/container/dracut-initrd/bin/set-local-sysroot.sh
+      - 然后将这个lv作为本次要使用的文件系统，并启动它，开始执行job。
+
+
+#### 3.4.3.2 物理机使用local的rootfs流程
+
+物理机使用local的rootfs流程与[3.4.2.2 物理机使用cifs/nfs的rootfs流程](./cifs-nfs-hw.md)大致相同，不同点见上面的“3.4.3.1 虚拟机使用local的rootfs流程”部分的两个不同点。
+
diff --git a/doc/help/rootfs/how-to-get-rootfs/README.md b/doc/help/rootfs/how-to-get-rootfs/README.md
new file mode 100644
index 000000000000..74673df0a9b0
--- /dev/null
+++ b/doc/help/rootfs/how-to-get-rootfs/README.md
@@ -0,0 +1,35 @@
+### 3.2.1 从compass-ci官方下载
+
+待补充
+
+### 3.2.2 通过自动化工具制作rootfs
+
+#### 3.2.2.1 自动化制作os_mount=container的rootfs
+
+待补充
+
+#### 3.2.2.2 自动化制作os_mount=cifs/nfs的rootfs
+
+[3.2.2.2 自动化制作os_mount=cifs/nfs的rootfs](./auto-generate-cifs-nfs.md)
+
+#### 3.2.2.3 自动化制作os_mount=local的rootfs
+
+待补充
+
+#### 3.2.2.4 自动化制作os_mount=initramfs的rootfs
+
+待补充
+
+### 3.2.3 通过手动方式制作rootfs
+
+#### 3.2.3.1 手动制作os_mount=container的rootfs
+
+待补充
+
+#### 3.2.3.2 手动制作os_mount=cifs/nfs/local的rootfs
+
+[3.2.3.2 手动制作os_mount=cifs/nfs/local的rootfs](./manual-generate-cifs-nfs-local.md)
+
+#### 3.2.3.3 手动制作os_mount=initramfs的rootfs
+
+[3.2.3.3 手动制作os_mount=initramfs的rootfs](./manual-generate-initramfs.md)
diff --git a/doc/help/rootfs/how-to-get-rootfs/auto-generate-cifs-nfs.md b/doc/help/rootfs/how-to-get-rootfs/auto-generate-cifs-nfs.md
new file mode 100644
index 000000000000..8a848f947cd0
--- /dev/null
+++ b/doc/help/rootfs/how-to-get-rootfs/auto-generate-cifs-nfs.md
@@ -0,0 +1,97 @@
+#### 3.2.2.2 自动化制作os_mount=cifs/nfs的rootfs
+
+**说明：由于自动化天然有其有限性，故此种方式有其支持的[iso范围](https://gitee.com/ycvayne/iso2qcow2/tree/master/conf/ks)，如果需要制作的iso版本不在支持的iso范围中，请参考下面的手动安装iso制作rootfs部分**
+
+在本地compass-ci集群中，提交iso2rootfs.yaml即可
+
+```
+zhangsan@localhost ~% cat iso2rootfs-21.09.yaml
+suite: iso2rootfs
+category: benchmark
+iso2rootfs:
+  #################
+  # iso related fields to be used to generate rootfs
+  #################
+
+  iso_os: openeuler
+  iso_arch: aarch64
+  iso_version: 21.09
+
+  #################
+  # place the result rootfs related fields
+  #################
+
+  # 1. Result rootfs will be placed in the following location on the
+  #    remote file server:
+  #    - {remote_file_server}/{rootfs_path}/{iso_os}/{iso_arch}/
+  # 2. Remote file server protocols current supported:
+  #    - nfs
+  #    - cifs
+  rootfs_protocol: cifs
+  rootfs_server: 1.1.1.1
+  rootfs_path: os-rw
+  rootfs_mount_param: guest,vers=1.0,noacl,nouser_xattr
+
+  initramfs_protocol: cifs
+  initramfs_server: 1.1.1.1
+  initramfs_path: initrd/osimage
+  initramfs_mount_param: port=446,guest,vers=1.0,noacl,nouser_xattr
+
+  #################
+  # config rootfs related fields
+  #################
+
+  # you can config add some configurations of the result rootfs.
+  # supported fields:
+  # - dns: will config /etc/resolv.conf.
+  # - no_selinux: will disable selinux in /etc/selinux/config.
+  # - no_fstab: will comment all line in /etc/fstab.
+  # - enable_repos: will enable all repo file of result rootfs.
+  config_rootfs: no_selinux, no_fstab
+
+  ## install pkgs for result rootfs
+  ## - example: vim, git, xxx
+  rootfs_install_pkgs:
+
+  #################
+  # iso srouce related fields
+  #################
+
+  # iso url which you want generate rootfs from
+  # - demo:
+  #   iso_url: http://1.1.1.1/openEuler-20.03-LTS-aarch64-LTS/openEuler-20.03-LTS-aarch64-d...
+
+  iso_url: http://1.1.1.1:8000/os/install/iso/openeuler/aarch64/21.09/openEuler-21.09-a...
+
+  # dailybuild_iso_url_file:
+  # - The `dailybuild iso url file` content is the url of a iso.
+  # - The iso checksum file also exists on the network, and the checksum file path is "{dailybuild_iso_url}.check256sum"
+  # - if your have this field, the above `iso_url` field will be useless.
+  # - demo:
+  #   dailybuild_iso_url_file: http://1.1.1.1/dailybuilds/openEuler-20.03-LTS-aarch64-LTS/release_iso
+  #     root@localhost ~% curl http://1.1.1.1/dailybuilds/openEuler-20.03-LTS-aarch64-LTS/release_iso
+  #     http://1.1.1.1//dailybuilds/openEuler-20.03-LTS-aarch64-LTS/1970-01-01-00-00...
+  dailybuild_iso_url_file:
+
+  #################
+  # submit test yaml related fields
+  #################
+
+  # submit target tests yaml
+  ## 1. You can add as many jobs as you like.
+  ## 2. The following three fields is required for every test job.
+  test1_yaml: iperf.yaml
+  test1_os_mount: initramfs
+  test1_testbox: vm-2p16g
+  ## the following three fields is required when your job.yaml and
+  ## script for this test are from the internet.
+  test1_git_url:
+  test1_git_yaml:
+  test1_git_script:
+
+secrets:
+  MY_EMAIL: XXXXXXXXXXX@163.com
+  MY_NAME: zhangsan
+  MY_TOKEN: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+zhangsan@localhost ~% #submit -m ./iso2rootfs-21.09.yaml testbox=taishan200-2280-2s64p-128g--a108
+```
diff --git a/doc/help/rootfs/how-to-get-rootfs/manual-generate-cifs-nfs-local.md b/doc/help/rootfs/how-to-get-rootfs/manual-generate-cifs-nfs-local.md
new file mode 100644
index 000000000000..97160f70eb9c
--- /dev/null
+++ b/doc/help/rootfs/how-to-get-rootfs/manual-generate-cifs-nfs-local.md
@@ -0,0 +1,58 @@
+#### 3.2.3.2 手动制作os_mount=cifs/nfs/local的rootfs
+
+**说明：从本质上来讲，cifs/nfs/local所需的rootfs是可以共用的，所以，如果你制作出了local类型的rootfs，那么cifs/nfs均可以使用此rootfs。**
+
+1. 手动安装iso到物理机A # 此步骤无说明，请自行百度
+   - 硬盘可选任意一块硬盘A；
+   - 安装完毕，一般会提示“按Enter键重启系统”。
+2. firstboot
+   - 在1步骤的“按Enter键重启系统”，启动系统后，不要做任何操作，直接reboot再次重启系统
+3. 将物理机A上的硬盘A中的系统拷贝到指定目录。 # 如：/srv/os/${os}/${os_arch}/${os_version}-20211129000000
+   - 使用物理机A上的非A硬盘中的系统启动物理机A
+     - 使用位于物理机A上的其他硬盘的系统启动物理机A
+     - 可以给物理机A提交一个内存文件系统的job（此job不限制os,os_arch,os_version）
+   - 在物理机A上，拷贝硬盘A中的系统到指定目录。
+     - 通过nfs/cifs协议挂载你的Compass-CI集群主节点的/srv/os/${os}/${os_arch}/${os_version}-20211129000000至/mnt1； # rw读写模式
+     - 挂在硬盘A至/mnt2
+     - rsync -a /mnt2/. /mnt
+   - 释放物理机A
+4. 对指定目录的rootfs进行一些处理
+   - 解压内核并生成${rootfs}/boot/vmlinuz
+     - 解压内核(ipxe需要)：如果你的内核格式中有gzip字样，请参考下面的解决文档解决
+       参考：
+       - file: https://gitee.com/wu_fengguang/compass-ci/blob/master/container/qcow2rootfs/...
+       - function: unzip_vmlinuz
+     - 生成vlinuz软链接（compass-ci代码逻辑需要）：
+       ```
+       root@z9 /srv/os/openeuler/aarch64/20.03-iso# ll boot | grep vmlinuz
+       -rwxr-xr-x  1 root root 7.1M 2021-06-29 20:56 vmlinuz-0-rescue-8f22ff33e906472498de4a5b3fc087ef
+       -rw-rw-r--  1 root root  20M 2021-06-29 21:10 vmlinuz-4.19.90-2003.4.0.0036.oe1.aarch64
+       lrwxrwxrwx  1 root root   43 2021-06-29 21:10 vmlinuz -> ./vmlinuz-4.19.90-2003.4.0.0036.oe1.aarch64
+       ```
+   - 生成${rootfs}/boot/modules.cgz（compass-ci代码逻辑需要）
+     参考：
+     - file: https://gitee.com/wu_fengguang/compass-ci/blob/master/container/qcow2rootfs/...
+     - function: create_get_modules
+   - 生成${rootfs}/initrd.lkp（compass-ci代码逻辑需要）
+     参考：
+     - file: https://gitee.com/wu_fengguang/compass-ci/blob/master/container/qcow2rootfs/...
+     - function: create_get_initrd
+   - 注释掉${rootfs}/etc/fstab的启动项（compass-ci代码逻辑需要）
+     参考：
+     - file: https://gitee.com/wu_fengguang/lkp-tests/blob/master/tests/iso2rootfs
+     - function: disable_fstab
+   - 关闭${rootfs}的selinux
+     参考：
+     - file: https://gitee.com/wu_fengguang/lkp-tests/blob/master/tests/iso2rootfs
+     - function: disable_selinux
+   - 创建真实版本的软链接
+     ```
+     root@z9 /srv/os/openeuler/aarch64# ll -d 20.03-iso*
+     dr-xr-xr-x 1 root root 190 2021-08-24 09:09 20.03-iso-2021-08-24-18-01-07
+     dr-xr-xr-x 1 root root 190 2021-08-24 09:09 20.03-iso-2021-08-24-09-07-18
+     lrwxrwxrwx 1 root root  29 2021-08-24 18:16 20.03-iso -> 20.03-iso-2021-08-24-18-01-07
+     ```
+5. 使用制作出来的rootfs提交job
+   ```
+   root@localhost ~% submit -m -c borrow-1d.yaml testbox=vm-2p16g os=openeuler os_version=20.03-iso os_mount=cifs
+   ```
diff --git a/doc/help/rootfs/how-to-get-rootfs/manual-generate-initramfs.md b/doc/help/rootfs/how-to-get-rootfs/manual-generate-initramfs.md
new file mode 100644
index 000000000000..d7e5553dd165
--- /dev/null
+++ b/doc/help/rootfs/how-to-get-rootfs/manual-generate-initramfs.md
@@ -0,0 +1,39 @@
+#### 3.2.3.3 手动制作os_mount=initramfs的rootfs
+
+1. 将制作出来的相同${os},${os_arch},${os_version}的os_mount=cifs/nfs/local的rootfs拷贝一份到临时目录。
+   ```bash
+   mkdir /srv/os/openeuler/aarch64/20.03-iso-tmp
+   rsync -a /srv/os/openeuler/aarch64/20.03-iso-2021-08-24-18-01-07/. /srv/os/openeuler/aarch64/20.03-iso-tmp/
+   ```
+2. 进入临时目录，删掉一些不需要加入到initamfs系统的文件
+
+   **说明：也可以不删除这些文件，如果你知道你需要它们**
+   ```bash
+   cd /srv/os/openeuler/aarch64/20.03-iso-tmp/
+   rm -rf lib/modules/*
+   rm -rf boot/vmlinuz*
+   rm -rf boot/initr*
+   ```
+
+ 3. 生成initramfs的rootfs
+   ```bash
+   ############
+   # 为什么要去掉${os_version}的-iso后缀：
+   # - 目前，只有os_mount=local对应的rootfs需要-iso后缀，initramfs不需要
+   ############
+
+   initramfs_cgz=/srv/initrd/osimage/$os/$os_arch/${os_version%-iso}/$(date +"%Y%m%d").0.cgz
+   mkdir -p $(dirname $initramfs_cgz)
+   cd /srv/os/openeuler/aarch64/20.03-iso-tmp/
+   find . |cpio -o -Hnewc | gzip -9 > $initramfs_cgz
+
+   cd $(dirname $initramfs_cgz)
+   ln -sf $(basename $initramfs_cgz) current
+
+   ############
+   # 如何获得../../../../deps/nfs/debian/aarch64/sid/run-ipconfig.cgz：
+   # - 从Compass-CI官网下载：https://api.compass-ci.openeuler.org:20008/initrd/deps/nfs/debian/aarch64/si...
+   ############
+
+   ln -sf ../../../../deps/nfs/debian/aarch64/sid/run-ipconfig.cgz run-ipconfig.cgz
+   ```
-- 
2.23.0

    

Wu Fengguang

tags

participants (1)