本文主要介绍在 MacOS 上使用 qemu 搭建 Linux Kernel 的开发环境。(在开始之前需要注意的是,本文中的 Linux 开发环境是基于 Docker 搭建的,而 qemu 通过 homebrew 源码编译安装在本地的 MacOS 上)

1. 为什么需要 qemu?

qemu 是一个硬件虚拟化程序(hypervisor that performs hardware virtualization),与传统的 VMware / VirtualBox 之类的虚拟机不同,它可以通过 binary translation 模拟各种硬件平台(比如在 x86 机器上模拟 ARM 处理器)。而 VirtualBox 等更多是通过虚拟化来进行资源隔离,以便在其上运行多个 guest os。

基于 qemu 的硬件模拟能力,我们可以轻松搭建指定硬件平台的运行实验环境。

qemu 与 VirtualBox 另一个不同点在于,在 VirtualBox 上必须安装一个完整的操作系统套件,而通过 qemu 我们可以通过参数直接启动到一个裸的 Linux Kernel,连 bootloader 都不需要关心。在此之外,按需配置相关工具套件与启动好的 Kernel 一起工作即可。

qemu 提供的这种高度可定制化的『白盒』能力,使得我们可以按需构建快速、轻量级的开发环境,提供流畅的开发体验。

2. 环境准备

首先,为了进行内核的编译,需要一个现成的 Linux 操作系统环境。当然,你也可以在Mac上配置交叉编译链,但是这样比较麻烦,而且可能出现一些无法预料的问题,所以这里建议使用一个现成的 Linux 操作系统来编译内核。

可以是一个通过 ssh 工作的远程 Linux Server,或者也可以在 MacOS 上通过 VirtualBox (或者使用 qemu 也可以)安装一个虚拟机用于开发。VirtualBox 的安装和 Linux Guest OS 的安装配置此处略过不提。

此处我们使用Docker来搭建Linux环境,系统选用的是Ubuntu 20.04。运行一个Ubuntu的Docker容器:

$ docker run -it --privileged --platform linux/amd64 -v /Users/thomas/Projects/ubuntu-projects:/root/projects/ --name ubuntu ubuntu:20.04

--privileged是为了防止mount命令没有权限,但是实际上Mac上的Docker确实没法用mount命令,所以这个参数其实没什么用。--platform linux/amd64表示运行x86_64版本的Ubuntu。

进入容器后安装编译工具链:

$ sudo apt install build-essential

由于将要编译32位的程序,需要把32位的GCC库也装上(否则之后编译32位的busybox会报错):

$ sudo apt install gcc-multilib

接下来,安装 qemu。在 MacOS 上可以使用 Homebrew 包管理工具进行安装(本文使用的 qemu 版本为 7.1.0):

brew install qemu

安装完成后,可以看到系统中有很多个 qemu-system- 开头的命令,用于模拟各种硬件平台,比如 qemu-system-i386 。运行其中一个命令来验证安装是否成功:

qemu-system-i386

上述命令会启动一个类似 VirtualBox 虚拟机启动时的窗口。当然,由于我们没有指定任何设备,最终会提示找不到可启动设备。

3. 编译内核

按需编译内核,此处只进行简单说明(基于内核v5.4.215)。

3.1 内核编译配置

可以先执行 make help 可以查看 make 支持哪些 target。

通常先进行内核编译配置:

$ make menuconfig

会启动一个基于文本的配置界面进行各种选项、模块、驱动等配置。如果出错提示找不到curses.h,那么就是缺少了一个依赖,执行:

$ sudo apt install libncurses5-dev

或者也可以直接使用目标平台默认的配置,如针对 x86_64 平台(后续平台相关的地方均以 x86_64 为例进行说明)可以使用:

$ make x86_64_defconfig

这里我们关闭64位的选项,即默认编译32位的内核。

    General setup  ---> 
[ ] 64-bit kernel (NEW)
Processor type and features --->
...

配置完成后相应的配置项会保存在 .config 文件中。下一次执行 make menuconfig 时可以 load 这份配置文件,在此基础上进行修改。

3.2 编译内核和模块

我们构建一个压缩过的内核镜像:

make bzImage -j8

编译成功后,bzImage 文件将出现在 arch/x86_64/boot/bzImage。记住文件路径或者拷贝到一个方便的路径,便于后续启动时使用。 接下来,编译在配置阶段选择的内核模块:

make modules

编译好的内核模块 *.ko 文件存在于模块对应的源码目录中。

4. 启动内核

编译好内核以后,我们就可以使用 qemu 启动内核了。只需要使用 -kernel 参数告诉 qemu 内核文件的位置即可:

qemu-system-i386 
-m 512M # 指定内存大小
-smp 4 # 指定虚拟的 CPU 数量
-kernel ./bzImage # 指定内核文件路径
-nographic # 不开启图形界面
-append "console=ttyS0" # 设置控制台输出 否则一片黑

上述命令假设编译好的 bzImage 内核文件就存放在当前目录下。因为之前编译好的内核文件是在 VirtualBox 的虚拟机中(或者在远程服务器上),而 qemu 在本地 MacOS 上,可以通过 VirtualBox 的 share folder 来共享目录,或者使用 NFS 共享,甚至简单使用 rsync 来在两者之间同步文件。后续关于文件同步与共享不再赘述。

不出意外的话,就可以在启动窗口中看到内核的启动日志了。在内核启动的最后,会出现一条 panic 日志:

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0, 0)

从日志内容可以看出,内核启动到一定阶段后尝试加载根文件系统,但我们没有指定任何磁盘设备,所以无法挂载根文件系统。而且上一节中编译出来的内核模块现在也没有用上,内核模块也需要存放到文件系统中供内核需要的时候进行加载。

要退出Qemu,按下组合键ctrl-a然后松开再按c,就能进入Qemu控制台,这时候再输入q即可退出。ctrl-a h是进入帮助界面。

接下来需要制作一个磁盘镜像文件供内核作为根文件系统加载。

5. 制作磁盘镜像

如上一节所述,需要制作一个磁盘镜像文件作为根文件系统供内核加载,同时也用于存放编译好的内核模块,以及后续所需的各种配套工具程序。

制作根文件系统镜像文件思路:

  1. 先制作一个空的镜像文件;
  2. 然后把此镜像文件格式化为ext3格式;
  3. 然后把此镜像文件挂载,并把根文件系统复制到挂载目录;
  4. 卸载该镜像文件;
  5. 打包。

5.1 创建磁盘镜像文件

使用 qemu-img 创建一个 512M 的磁盘镜像文件:

qemu-img create -f raw disk.raw 512M

现在 disk.raw 文件就相当于一块磁盘,为了在里面存储文件,需要先进行格式化,创建文件系统。比如在 Linux 系统中使用 ext4 文件系统进行格式化:

mkfs -t ext4 ./disk.raw

5.2 挂载磁盘镜像文件

格式化完成之后,可以在 Linux 系统中以 loop 方式将磁盘镜像文件挂载到一个目录上,这样就可以操作磁盘镜像文件中的内容了。 下面的命令将磁盘镜像文件挂载到 img 目录上:

sudo mount -o loop ./disk.raw ./img

5.3 安装内核模块

现在可以将之前编译好的内核模块安装到磁盘镜像中了。命令如下:

sudo make modules_install  # 安装内核模块
INSTALL_MOD_PATH=./img # 指定安装路径

执行完成后即可在 ./img/lib/modules/ 下看到安装好的内核模块。

5.4 使用磁盘镜像文件作为根文件系统

准备好磁盘镜像文件后,使用下面的命令再次启动 qemu:

qemu-system-i386
-m 512M
-smp 4
-kernel ./bzImage
-drive format=raw,file=./disk.raw # 指定文件作为磁盘
-nographic # 不开启图形界面
-append "root=/dev/sda console=ttyS0" # 设置控制台输出 否则一片黑

这一次,内核不再报根文件系统找不到了。但是报了另一个错误:

Kernel panic - not syncing: No working init found. Try passing init= option to Kernel. See Linux Documentation/admin-guide/init.rst for guidance.

这说明内核启动已经接近完成了,准备启动 1 号进程,也就是 init 进程。但我们的启动参数里面没有指定 init 选项,而且磁盘镜像中也没有相应的 init 程序。因此,接下来需要准备一个 init 程序供内核启动。

6. 准备 init 程序

常用的 init 程序有下面几种:

  • sysv init:传统 Linux 系统中最常用的 init 程序
  • systemd:目前最流行的 init 程序,很多主流发行版都已经切换到 systemd。systemd 针对 sysv init 启动速度慢、无法并行以及管控能力弱等问题进行了重新设计。参见 Rethinking PID 1
  • busybox init:通知用在嵌入式等小型系统中。除了 init 程序外,busybox 还包含了很多常用的命令工具,比如 lscat 等。busybox 非常轻量级,可以编译出完全独立无依赖的 busybox 套件。

这里选用 busybox 作为 init 程序及其它命令工具的提供者。

6.1 编译 busybox

下载 busybox 的源码到 Linux 系统中,准备进行编译,这里使用的 busybox 版本为 1.35.0。

busybox 的编译流程与内核很像,这里我们基于默认配置进行编译。首先,执行如下命令让默认配置生效:

make defconfig

接下来,在默认配置的基础上进行定制:

make menuconfig

这里有一个重要的配置,因为 busybox 将被用作 init 程序,而且我们的磁盘镜像中没有任何其它库,所以 busybox 需要被静态编译成一个独立、无依赖的可执行文件,以免运行时发生链接错误。配置路径如下:

Busybox Settings --->
--- Build Options
[*] Build BusyBox as a static binary (no shared libs)

另外,因为我们要编译的是32位的busybox,所以要给gcc和ld都加上-m32的选项(即添加CFLAG和LDFLAG)。

最后,配置完成后执行编译:

make -j8

编译完成后在当前目录下可以看到 busybox 可执行文件,查看大小才 2.5M 左右。整个 busybox 套件只有这一个可执行文件,里面包含了若干工具。比如:

./busybox ls -l
./busybox ps

6.2 安装 busybox 到磁盘镜像

编译好 busybox 之后需要将其安装到磁盘镜像中以供使用。

首先安装busybox:

$ make install

默认情况下会将busybox安装在源码目录下的_install文件夹中。可以查看下目录结构:

$ ls _install/
bin linuxrc sbin usr

也执行如下命令进行安装:

$ make CONFIG_PREFIX=<path_to_disk_img_mount_point> install

CONFIG_PREFIX 用于指定安装路径,需要指定到之前磁盘镜像文件的挂载目录,比如 ./img。进入磁盘镜像挂载目录查看,常见的文件系统结构已经建立起来了。查看 bin 和 sbin 目录下的命令,可以看到都是链接到 bin/busybox 的,busybox 会根据执行时的文件名来执行不同的功能。

我们这里也直接用cpio命令打包一个磁盘镜像文件。进入到_install目录下,执行:

$ find . | cpio -o --format=newc > ../rootfs.img

就会在上层目录中生成rootfs.img这个镜像文件。

6.3 使用 busybox 作为 init 程序

busybox 安装完成之后,使用内核启动参数 init= 来指定 busybox 作为 init 程序,再次尝试启动。

$ qemu-system-i386
-m 512M
-smp 4
-kernel bzImage
-drive format=raw,file=./disk.raw
-nographic # 不开启图形界面
-append "init=/linuxrc root=/dev/sda console=ttyS0"

或者:

$ qemu-system-i386 -m 512M -smp 4 -kernel bzImage -nographic \
-append "console=ttyS0 root=/dev/ram rdinit=sbin/init" \
-initrd rootfs.img

上述命令通过 init=/linuxrc 指定了 init 程序为根目录下的 linuxrc,实际上是一个指向 busybox 的软链接。

这一次内核成功找到了 init 程序并且创建出 init 进程,但是 init 执行过程中出现如下报错:

can't run '/etc/init.d/rcS': No such file or directory

can't open /dev/tty3: No such file or directory
can't open /dev/tty4: No such file or directory

看样子,init 程序需要一些配置才能正常运行起来。

6.4 配置 busybox init

参考 busybox 代码中的 文档 可知,init 启动后会扫描 /etc/inittab 配置文件,这个配置文件决定了 init 程序的行为。而 busybox init 在没有 /etc/inittab 文件的情况下也能工作,因为它有默认行为。它的默认行为相当于如下配置:

::sysinit:/etc/init.d/rcS
::askfirst:/bin/sh
::ctrlaltdel:/sbin/reboot
::shutdown:/sbin/swapoff -a
::shutdown:/bin/umount -a -r
::restart:/sbin/init
tty2::askfirst:/bin/sh
tty3::askfirst:/bin/sh
tty4::askfirst:/bin/sh

参考文档,接下来进入_install目录,补充一些必要的文件或目录。

我们提供一份 etc/inittab 配置文件如下:

::sysinit:/etc/init.d/rcS
::askfirst:/bin/sh
::ctrlaltdel:/sbin/reboot
::shutdown:/sbin/swapoff -a
::shutdown:/bin/umount -a -r
::restart:/sbin/init

并且根据配置,我们需要创建可执行文件 etc/init.d/rcS,内容如下(暂时什么事都不做):

echo -e "\nWelcome to tiny Linux\n"
#!/bin/sh

记得赋予可执行权限:

$ chmod +x etc/init.d/rcS

配置完成以后再次尝试启动,这次将成功启动,并且出现如下提示:

Please press Enter to activate this console.

按提示按下 Enter 键之后将会启动 shell,进行到我们熟悉的环境,可以执行各种常用命令了。

6.5 挂载 /dev, /proc, /sys 文件系统

查看当前系统环境,会发现当前文件系统结构是不完整的。比如没有 /dev, /proc 以及 /sys 挂载点。这样我们无法通过 /dev 查看系统中的设备,如果执行 df 命令也会因为没有 /proc 挂载点而报错:

$ df: /proc/mounts: No such file or directory

因此,我们需要手工创建 /dev, /proc, /sys 这三个目录。/dev 目录创建完成后重启系统即可工作,但 /proc 和 /sys 需要执行挂载才可工作,可以将 /proc 和 /sys 的挂载动作放到 /etc/init.d/rcS 中,每次系统启动时自动挂载。修改 /etc/init.d/rcS 内容如下:

echo -e "\nWelcome to tiny Linux\n"
#!/bin/sh
mount -t proc proc /proc
mount -t sysfs sysfs /sys

重新启动系统查看,可以看到 /dev, /proc, /sys 挂载点都相应有了内容。

6.6 设置tty

最后,再加些内容,当内核引导系统时,它需要一些设备节点,特别是控制台和空设备。通过运行以下命令来创建它们:

mknod -m 600 /dev/console c 5 1
mknod -m 666 /dev/null c 1 3

我们在这里创建/dev/null和/dev/ttyS0:

echo -e "\nWelcome to tiny Linux\n"
#!/bin/sh
mount -t proc proc /proc
mount -t sysfs sysfs /sys

mknod -m 666 /dev/null c 1 3
mknod -m 666 /dev/ttyS0 c 4 64
echo -e "\nBoot took $(cut -d' ' -f1 /proc/uptime) seconds\n"
setsid cttyhack sh
exec /bin/sh

重新启动内核,即可正常运行。

7. 小结

查看系统版本:

$ cat /proc/version
Linux version 5.4.215 (root@5414496c293c) (gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)) #1 SMP Tue Oct 42

本文介绍了通过 qemu 作为模拟器,并且本地通过Docker容器编译内核,并从头配置 init 进程,构建出一个最小的可运行系统,可用于验证对内核的改动。 通过这次开发环境搭建,对Linux系统的启动过程有了一个粗略的了解。