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://$%7Bscheduler%7D:$%7Bport%7D/boot.ipxe/mac/$%7Bmac:hexhyp%7D + + exit + ``` + - 所以，到此步骤，物理机testbox已经与调度器建立了连接，等待job。 + + - 服务端（调度器）如果半个小时都没有调度到这个客户端的任务，就会给客户端返回如下返回值: + ``` + chain http://#%7BENV%5B%22SCHED_HOST%22%5D%7D:#%7BENV%5B%22SCHED_PORT%22%5D%7D/boo..." + ``` + - 物理机接收到此返回值，会继续请求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%5C%22,%... + ``` + +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%EF%B... + - 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)%EF%BC%8C%E5%A6%82%E... + +在本地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 + ```