【Linux】使用 QEMU + debootstrap 模拟 ARM64 运行环境

前言

由于项目需求，笔者最近需要在一个无网络环境且只能通过拷贝源码自行编译的方式准备项目所需的arm架构的开发环境及依赖项。

笔者在无意间找到了qemu-user-static + debootstrap这样的方式在宿主机上构建并进入一个 ARM64 RootFS，实现本地模拟不同架构的环境。

本机环境
image

一、ARM64 环境的安装、启动与验证

0. 省流(依次运行即可)

sudo apt install qemu-user-static debootstrap
sudo debootstrap --arch=arm64 focal ./arm64-rootfs http://ports.ubuntu.com/
sudo chroot ./arm64-rootfs
uname -a

1. 安装所需工具

首先在宿主机（通常为 x86_64 Linux）上安装 QEMU 用户态模拟器和 debootstrap：

sudo apt install qemu-user-static debootstrap
  • qemu-user-static 提供了针对不同架构的用户态指令模拟能力；
  • debootstrap 用于从官方仓库构建一个最小可用的 Linux RootFS。
    安装完成后，不需要额外配置即可继续后续步骤。

2. 使用 debootstrap 构建 ARM64 RootFS

sudo debootstrap --arch=arm64 focal ./arm64-rootfs http://ports.ubuntu.com/

该命令会在当前目录下生成一个 arm64-rootfs 目录，其中包含一个最小的 ARM64 Ubuntu 用户空间。
!注意上述命令当前目录下生成，具体路径可以根据实际需求进行修改
说明：

  • --arch=arm64 明确指定目标架构；
  • focal 为发行版代号；
  • http://ports.ubuntu.com/ 是 Ubuntu 为非 x86 架构提供的软件仓库。

该过程会下载并解包大量基础包，视网络情况需要较长时间。

3. 进入 ARM64 环境（chroot）

RootFS 构建完成后，直接使用 chroot 进入：

sudo chroot ./arm64-rootfs

进入后，Shell 提示符会切换到 RootFS 内部，此时你已经处于一个 ARM64 用户空间环境。

4. 验证当前是否为 ARM64 环境

image

二、命令与机制原理说明

  1. qemu-user-static 并不是完整系统虚拟化（如 qemu-system），而是用户态指令翻译器。内核仍然是宿主机内核，只是用户态程序是 ARM64 架构。
  2. debootstrap 的作用并不是“安装系统”，从指定仓库下载一组最小化的 .deb 包；解压并组织成一个合法的 Linux 目录结构；构建一个 可被 chroot 的用户空间。
  3. chroot 为什么能“进入” ARM 系统?
    chroot 的本质是：修改当前进程看到的根目录 /,并且限制进程只能访问指定目录树，它并不切换内核，也不切换 CPU 架构
    chroot 只是提供了一个“看起来像 ARM 系统”的文件系统视角。

三. Q&A

Q1.什么是 qemu-user-static 的“用户态模拟”？它与虚拟机、Docker 的区别和联系是什么？

  • 用户态模拟（User-mode Emulation）指的是,仅对用户空间程序的CPU 指令进行模拟与翻译，而不模拟完整的硬件系统与内核。
  • 在 qemu-user-static 模式下：
    • 宿主机 内核保持不变
    • 目标架构（如 ARM64）的程序在用户态运行
    • ARM 指令在运行时被翻译为宿主机（如 x86_64）指令
  • 对比其他技术
    image

Q2：为什么用户态模拟不需要启动 ARM 内核？

在用户态模拟中：

  1. ARM 程序的 CPU 指令 被 QEMU 翻译执行；
  2. 系统调用被转换为 宿主机内核可理解的等价调用。

因此：不存在 ARM 内核,所有系统调用最终仍由宿主机内核完成
通过uname -r可以看出，显示的是宿主机内核版本，而不是 ARM 内核。

Q3：用户态模拟相比其他模拟方式的优势在哪里？

  1. 启动成本极低
    不需要内核镜像，不需要虚拟机那样的硬件模拟，整个流程通过几个简单的命令加上最后的chroot进入环境
  2. 资源占用小，适合批量使用
    没有完整系统进程树，不占用额外内存模拟设备
  3. 与宿主系统集成度高
    在这个arm架构下所有的文件系统都可以通过宿主机进入查看
    这也对于笔者这种需要将部分arm软件包拷贝出来用于其他的项目场景十分有效

Q4：用户态模拟的主要局限性是什么？

  1. 无法测试内核态行为并且对硬件依赖程序支持有限
    根据上个问题的优势也可以看到，由于没有模拟硬件，因此无法用于验证arm的驱动，
    没有真正的创建并使用内核，也无法测试内核模块
    没有模拟硬件，因此也很做到对于硬件的测试支持等
  2. 性能并非线性可预期
    由于整体是通过qemu对于arm指令进行翻译运行，因此实际的命令运行效率相对而言并没有很好

Q5：这种方式适合生产环境吗？

通过上述内容也可以看到，这种方式更适合于构建环境，开发验证等内容，对于实际的部署，由于缺少硬件，内核的支持以及考虑到arm命令翻译导致性能丢失的问题，实际上不适用于生产部署环境。

posted @ 2025-12-14 17:18  TICSMC  阅读(110)  评论(0)    收藏  举报