mailweb.openeuler.org
Manage this list
×
Keyboard Shortcuts
Thread View
j
: Next unread message
k
: Previous unread message
j a
: Jump to all threads
j l
: Jump to MailingList overview
2024
December
November
October
September
August
July
June
May
April
March
February
January
2023
December
November
October
September
August
July
June
May
April
March
February
January
2022
December
November
October
September
August
July
June
May
April
March
February
January
2021
December
November
October
September
August
July
June
May
April
March
February
January
2020
December
November
October
September
List overview
Download
Compass-ci
December 2021
----- 2024 -----
December 2024
November 2024
October 2024
September 2024
August 2024
July 2024
June 2024
May 2024
April 2024
March 2024
February 2024
January 2024
----- 2023 -----
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
----- 2022 -----
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
----- 2021 -----
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
----- 2020 -----
December 2020
November 2020
October 2020
September 2020
compass-ci@openeuler.org
1 participants
3 discussions
Start a n
N
ew thread
[PATCH compass-ci] doc: add doc of rootfs
by Wu Fengguang
05 Dec '21
05 Dec '21
Signed-off-by: Yu Chuan <13186087857(a)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/…
+ initrd
http://172.168.131.113:8000/os/openeuler/aarch64/20.03-2021-05-18-15-08-52/…
+ 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/9f87e65401d649095bacd…
+ kernel
http://172.168.131.113:8000/os/openeuler/aarch64/20.03-2021-05-18-15-08-52/…
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/…
+ initrd
http://172.168.131.113:8000/os/openeuler/aarch64/20.03-2021-05-18-15-08-52/…
+ 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/9f87e65401d649095bacd…
+ kernel
http://172.168.131.113:8000/os/openeuler/aarch64/20.03-2021-05-18-15-08-52/…
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/…
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/9f87e65401d649095bacd…
"]"} + ``` + +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/…
+ initrd
http://172.168.131.113:8000/os/openeuler/aarch64/20.03-2021-05-18-15-08-52/…
+ 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/9f87e65401d649095bacd…
+ kernel
http://172.168.131.113:8000/os/openeuler/aarch64/20.03-2021-05-18-15-08-52/…
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/…
+ initrd
http://172.168.131.113:8800/initrd/deps/initramfs/debian/aarch64/sid/run-ip…
+ initrd
http://172.168.131.113:8800/initrd/deps/initramfs/openeuler/aarch64/20.03/l…
+ 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/9f87e65401d649095bacd…
+ kernel
http://172.168.131.113:8000/os/openeuler/aarch64/20.03-2021-05-18-15-08-52/…
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/…
+ initrd
http://172.168.131.113:8000/os/openeuler/aarch64/20.03-2021-05-18-15-08-52/…
+ 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/9f87e65401d649095bacd…
+ kernel
http://172.168.131.113:8000/os/openeuler/aarch64/20.03-2021-05-18-15-08-52/…
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/9f87e65401d649095bacd…
+ 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-…
+ + iso_url:
http://1.1.1.1:8000/os/install/iso/openeuler/aarch64/21.09/openEuler-21.09-…
+ + # 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-0…
+ 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(a)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/sid/ + ############ + + ln -sf ../../../../deps/nfs/debian/aarch64/sid/run-ipconfig.cgz run-ipconfig.cgz + ``` -- 2.23.0
1
0
0
0
test
by FengGuang Wu
05 Dec '21
05 Dec '21
1
0
0
0
test
by Wu Fengguang
05 Dec '21
05 Dec '21
1
0
0
0
Results per page:
10
25
50
100
200