本篇文章，聊一聊尝试让安卓手机原生运行 Ubuntu，尤其是运行官方未发布过的 ARM 架构的 Ubuntu 24.04 桌面版本。
写在前面
最近的几篇文章，都包含了比较多的实操内容、需要反复的复现验证，以及大量的调试过程，为了不把内容沉底草稿箱，就先分章节发布出来啦。
之所以会有这篇文章，是因为写完最近几篇文章，后台收到了不少读者留言和私信，其中有几条是关于手机运行 Linux 操作系统，以及 Docker 性能问题的沟通。
在回复中，我提到了会在折腾恢复 Android 裁剪前的、适合 Docker 运行的内核环境，构建系统来验证为什么《Docker 加持的 安卓手机：随身携带的知识库（一）》这篇内容里，容器执行效率非常慢的问题。
但是，作为一个懒人，总归在想，有没有什么更简单的、更可持续的维护方案：
- 毕竟，每当安卓版本升级（包括 Linux 内核升级），如果我们想使用最新的系统，总归要重新构建和验证。
- 以及，在 Android 环境中，即使能够将 Docker 作为独立的可靠应用运行，但其实有很多程序，并不需要在容器中运行，如果本身就是 Linux 环境，那么折腾的成本不就更低了嘛。
况且，如果验证成功，之前写过的几十篇 Ubuntu、Docker 相关的文章不就都能有更轻量的验证环境了嘛。
不过，虽然目前 Ubuntu 官方推出了适用于 ARM 服务器的系统镜像。但是，官方压根没推出过桌面版本的 ARM 系统镜像。
想要得到 ARM 架构的 Ubuntu 24.04 桌面版的操作系统看起来只能由我们自己构建啦。（吗？）
作为一个懒人，能不动手就坚决不动手。 还记得更早些的一篇文章里，我在搭载了 M2 的 MacBook Pro 设备上安装了 24.04 版本的 Ubuntu 吗？这个操作系统就是桌面版本的。如果我们能够得到这个操作系统，那么可能能省不少功夫。
说干就干，至于跑 Windows 打游戏什么的，等干完正事再说吧。
不一样的 Ubuntu 系统历史：Ubuntu Phone 和 Ubuntu Touch
看完上面的内容，我相信有一些“互联网阅历”的朋友，一定会想起 “Ubuntu 移动操作系统”。但之所以不适配这个“更适合手机”的系统版本，而是选择适配标准版、更新的桌面版本，或许了解完它的故事，你会和我做出一样的选择。
在 2011 年，Ubuntu 宣布发布了适用于移动端、平板、电视等设备的分支操作系统：Ubuntu Touch。但是在 2017 年的时候，由于市场反馈不佳，Canonical 宣布停止维护该项目，随后改项目由 2015 年发起的 UBports 项目所在的基金会收购，原本官方支持的项目转变为了社区产品。
目前来看，这个系统支持的设备非常有限，参考资料也并不多，所以就不考虑从这个角度做“Linux 适配”啦。
另外一个有些关联，但是目前看来也步入历史尘埃的项目 Ubuntu Phone，将 Ubuntu 以 Android 系统方式融入手机，并提供使用 “QT、JS、HTML” 定义手机 App 的能力，也因为公司商业化方向调整，而被放弃，时间在 2014 年，比上面的 Touch 项目还更早一些。
自此以后，Ubuntu 官方就基本一心扑在“服务端”、“云市场”、“AI 市场”、“部分消费者日常笔电设备”上了。
第一步：获取预构建的 ARM 架构 Ubuntu 桌面版
回到《MacBook Pro 原生安装 Ubuntu 24.04 ARM 版》这篇文章里，我们使用的是 Asahi 项目的衍生项目 UbuntuAsahi/ubuntu-asahi，翻阅项目文档，我们不难得到项目的安装方法：
curl -sL https://ubuntuasahi.org/install | bash
如果我们将命令末尾的 | bash 删除，再次执行命令，就能够一窥安装脚本的庐山真面目啦：
# curl -sL https://ubuntuasahi.org/install
# ------
#!/bin/sh
# SPDX-License-Identifier: MIT
# Truncation guard
if true; then
set -e
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
export PATH="/usr/bin:/bin:/usr/sbin:/sbin:$PATH"
export VERSION_FLAG=https://cdn.asahilinux.org/installer/latest
export INSTALLER_BASE=https://cdn.asahilinux.org/installer
export INSTALLER_DATA=https://ubuntuasahi.org/installer_data.json
export REPO_BASE=https://files.tobhe.de/ubuntu
#TMP="$(mktemp -d)"
TMP=/tmp/asahi-install
echo "Bootstrapping installer:"
if [ -e "$TMP" ]; then
mv "$TMP" "$TMP-$(date +%Y%m%d-%H%M%S)"
fi
mkdir -p "$TMP"
cd "$TMP"
echo " Checking version..."
PKG_VER="$(curl --no-progress-meter -L "$VERSION_FLAG")"
echo " Version: $PKG_VER"
PKG="installer-$PKG_VER.tar.gz"
echo " Downloading..."
curl --no-progress-meter -L -o "$PKG" "$INSTALLER_BASE/$PKG"
if ! curl --no-progress-meter -L -O "$INSTALLER_DATA"; then
echo " Error downloading installer_data.json. GitHub might be blocked in your network."
echo " Please consider using a VPN if you experience issues."
echo " Trying workaround..."
curl --no-progress-meter -L -O "$INSTALLER_DATA_ALT"
fi
echo " Extracting..."
tar xf "$PKG"
echo " Initializing..."
echo
if [ "$USER" != "root" ]; then
echo "The installer needs to run as root."
echo "Please enter your sudo password if prompted."
exec caffeinate -dis sudo -E ./install.sh "$@"
else
exec caffeinate -dis ./install.sh "$@"
fi
fi
安装程序比较简单，基本就是定义一些“资源”，然后分别下载“真正的安装程序（installer）”和“安装程序数据（installer_data.json.json）”，然后调用安装程序，完成安装。
让我们使用 curl 来看看安装程序数据文件里都有些什么吧：
# curl https://ubuntuasahi.org/installer_data.json
{
"os_list": [
{
"name": "Ubuntu Desktop 23.10",
"default_os_name": "Ubuntu",
"boot_object": "m1n1.bin",
"next_object": "m1n1/boot.bin",
"package": "ubuntu-desktop-23.10-20240502.zip",
"supported_fw": ["12.3", "12.4", "13.5"],
"partitions": [
{
"name": "EFI",
"type": "EFI",
"size": "500MB",
"format": "fat",
"volume_id": "0xC3F44B40",
"copy_firmware": true,
"copy_installer_data": true,
"source": "esp"
},
{
"name": "Boot",
"type": "Linux",
"size": "2147483648B",
"image": "boot.img"
},
{
"name": "Root",
"type": "Linux",
"size": "12GB",
"expand": true,
"image": "root.img"
}
]
},
...
}
在 installer_data.json 中定义的内容，看起来就是我们要找的预构建好的 ARM 架构的系统镜像文件，虽然是 23.10 版本的 Ubuntu，但是我们可以和之前那篇文章一样，尝试升级系统到最新版本嘛。
不过，不论我们怎么和前面的安装程序中，预先定义好的路径进行拼合，就是无法下载到这个 ubuntu-desktop-23.10-20240502.zip 镜像压缩包。看来，需要研究下 Installer 这个隐藏在背后的真正的安装程序啦。
不论是选择使用 curl 模拟上面的逻辑，下载程序到本地，还是直接访问安装程序本体的开源项目 AsahiLinux/asahi-installer，我们都不难定位到位于 src/osinstall.py 的核心函数 load_package：
def load_package(self):
package = self.template.get("package", None)
if not package:
return
if not package.startswith("http"):
package = os.environ.get("REPO_BASE", ".") + "/os/" + package
logging.info(f"OS package URL: {package}")
if package.startswith("http"):
p_progress("Downloading OS package info...")
self.ucache = urlcache.URLCache(package)
self.pkg = zipfile.ZipFile(self.ucache)
else:
p_progress("Loading OS package info...")
self.pkg = zipfile.ZipFile(open(package, "rb"))
self.flush_progress()
logging.info(f"OS package opened")
原来在下载镜像的时候，程序会额外地做一个拼合动作，在地址中加一个 /os/ 目录。依样画葫芦，拼合上面得到的信息，得到能够下载的资源地址：
https://files.tobhe.de/ubuntu/os/ubuntu-desktop-23.10-20231107.zip
第二步：分析 ARM 架构镜像中的“素材”
使用 curl 或者下载工具完成预构建镜像的下载后，我们使用 unzip 对其解压缩，来看看里面有哪些东西：
# unzip ubuntu-desktop-23.10-20231107.zip
Archive: ubuntu-desktop-23.10-20231107.zip
inflating: boot.img
creating: esp/
creating: esp/m1n1/
inflating: esp/m1n1/boot.bin
creating: esp/EFI/
creating: esp/EFI/ubuntu/
inflating: esp/EFI/ubuntu/grub.cfg
inflating: esp/EFI/ubuntu/grubaa64.efi
creating: esp/EFI/BOOT/
inflating: esp/EFI/BOOT/BOOTAA64.EFI
inflating: root.img
可以看到镜像压缩包中，主要包含了三部分：
boot.img：根据名字来看是主要负责启动的分区镜像，具体内容需要还原分区后验证。esp：用于引导这个镜像的UEFI启动分区程序（EFI system partition的缩写就是esp）root.img：“根分区”镜像，看了下文件大小，足足有 8GB，应该是 Ubuntu 系统本体啦。
第三步：重新划分磁盘分区
上一篇文章中 “对手机进行分区调整” 小节中，我们介绍了如何对手机进行分区划分和处理。不过当时的目标是安装 Windows 系统，和现在的验证 Ubuntu 安装的场景需求不太匹配。
所以，我们来参考上篇文章，并略做调整，折腾出一个适用于上面 Ubuntu 镜像的环境：划分出三个新的分区。
恢复手机分区环境
重启手机并进入 “TWRP” 模式，确保 adb devices -l 能够“看到”你的设备：
# adb devices -l
List of devices attached
42cba029 recovery 1-1 product:raphael model:Xiaomi_Redmi_K20_Pro device:raphael transport_id:118
首先，还是使用 adb push 和 adb shell 命令，补全手机恢复环境中没有的 parted 工具，然后对 dev/block/sda 磁盘进行分区更新：
# adb push ./parted /sbin/
# adb shell "chmod +x /sbin/parted"
# adb shell parted /dev/block/sda
./parted: 1 file pushed, 0 skipped. 286.2 MB/s (922984 bytes in 0.003s)
GNU Parted 3.5
Using /dev/block/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted)
和上篇文章提到的一样，我们不要“摸黑”操作，先 print 确认下环境：
# (parted) print
print
Model: SAMSUNG KLUFG8R1EM-B0C1 (scsi)
Disk /dev/block/sda: 505GB
Sector size (logical/physical): 4096B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 24.6kB 32.8kB 8192B switch
2 32.8kB 65.5kB 32.8kB ssd
3 65.5kB 98.3kB 32.8kB dbg
4 98.3kB 131kB 32.8kB bk01
5 131kB 262kB 131kB bk02
6 262kB 524kB 262kB bk03
7 524kB 1049kB 524kB bk04
8 1049kB 1573kB 524kB keystore
9 1573kB 2097kB 524kB frp
10 2097kB 4194kB 2097kB bk05
11 4194kB 8389kB 4194kB misc
12 8389kB 12.6MB 4194kB vm-data
13 12.6MB 16.8MB 4194kB bk06
14 16.8MB 25.2MB 8389kB logfs
15 25.2MB 33.6MB 8389kB bk07
16 33.6MB 50.3MB 16.8MB oops
17 50.3MB 67.1MB 16.8MB devinfo
18 67.1MB 83.9MB 16.8MB oem_misc1
19 83.9MB 101MB 16.8MB ext4 metadata
20 101MB 134MB 32.9MB bk08
21 134MB 168MB 34.2MB splash
22 168MB 201MB 33.6MB bk09
23 201MB 268MB 67.1MB ext4 persist
24 268MB 336MB 67.1MB ext4 persistbak
25 336MB 403MB 67.1MB logdump
26 403MB 537MB 134MB minidump
27 537MB 671MB 134MB rawdump
28 671MB 738MB 67.1MB recovery
29 738MB 1007MB 268MB ext4 cache
30 1007MB 2080MB 1074MB ext4 cust
31 2080MB 32.0GB 29.9GB ext4 userdata
32 32.0GB 32.5GB 499MB esp boot, esp
33 32.5GB 485GB 453GB win msftdata
34 485GB 505GB 20.3GB fat32 armpe msftdata
能够看到分区和上一篇文章中的一致，在 userdata 目录后，保留着我们新划分的 esp、win、armpe 三个分区。
先来“恢复现场”，手动删除掉这三个分区，使用 rm + 分区编号即可：
# (parted) rm 32
rm 32
# (parted) rm 33
rm 33
# (parted) rm 34
rm 34
执行完分区的还原后，使用 p free 查看下分区状态：
30 1007MB 2080MB 1074MB ext4 cust
31 2080MB 32.0GB 29.9GB ext4 userdata
32.0GB 505GB 473GB Free Space
系统中由恢复了 473GB 的空余空间。
划分新分区
参考上篇文章中的操作，我们来重新划分 esp 分区，并设置分区可引导：
# (parted) mkpart esp fat32 32GB 32.5GB
mkpart esp fat32 32GB 32.5GB
# (parted) set 32 esp on
set 32 esp on
设置完毕，使用 p free 确认磁盘状况，以及确保上面的操作已经生效：
31 2080MB 32.0GB 29.9GB ext4 userdata
32.0GB 32.0GB 438kB Free Space
32 32.0GB 32.5GB 499MB fat32 esp boot, esp
32.5GB 505GB 473GB Free Space
接下来，我们分别创建用于存放上文中我们得到的 boot.img 分区镜像和 root.img 分区镜像的分区：
mkpart ubuntu-boot fat32 32.5GB 42.5GB
mkpart ubuntu-os ext4 42.5GB 505GB
当命令执行完毕，我们会看到类似下面的日志输出：
# (parted) mkpart ubuntu-boot fat32 32.5GB 42.5GB
mkpart ubuntu-boot fat32 32.5GB 42.5GB
# (parted) mkpart ubuntu-os ext4 42.5GB 505GB
mkpart ubuntu-os ext4 42.5GB 505GB
还是使用 p free 确认磁盘状况，确保上面的操作已经生效：
31 2080MB 32.0GB 29.9GB ext4 userdata
32.0GB 32.0GB 438kB Free Space
32 32.0GB 32.5GB 499MB fat32 esp boot, esp
33 32.5GB 42.5GB 10.0GB fat32 ubuntu-boot msftdata
34 42.5GB 505GB 463GB ext4 ubuntu-os
505GB 505GB 1028kB Free Space
好了，重启手机，让分区生效。
第四步：开始还原分区
接下来，我们来尝试将下载的 ARM 架构的镜像还原到上面准备好的手机分区中。
传输文件到手机内部存储
重启手机，等待手机再次进入“TWRP 模式”。
接着，先将刚刚我们下载并解压缩的 Ubuntu 镜像的三个部分传输到手机内的存储。这样可以确保我们在“还原磁盘”的过程中，不会出现数据线断开的麻烦事情。
# adb push /Users/soulteary/Downloads/esp/EFI /data/
# adb push /Users/soulteary/Downloads/boot.img /data/
# adb push /Users/soulteary/Downloads/root.img /data/
/Users/soulteary/Downloads/esp/EFI/: 4 files pushed, 0 skipped. 27.2 MB/s (5547908 bytes in 0.194s)
/Users/soulteary/Downloads/boot.img: 1 file pushed, 0 skipped. 33.4 MB/s (2147483648 bytes in 61.286s)
...
由于这台手机的 USB 接口是 2.0 协议，传输完毕所有文件，大概需要几分钟。如果你的手机内部存储空间比较有限，你可以先一个一个文件的传输并做还原，在还原后，手动删除掉传完的文件，来节约磁盘空间。
使用 adb shell 可以看到，大概需要消耗手机上 17G 的磁盘空间：
# adb shell df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 5.6G 288K 5.6G 1% /dev
tmpfs 5.6G 0 5.6G 0% /mnt
tmpfs 5.6G 32K 5.6G 1% /tmp
/dev/block/sda29 232M 248K 232M 1% /cache
/dev/block/sde52 320M 172M 148M 54% /firmware
/dev/block/sda31 27G 10G 17G 38% /data
使用 dd 还原磁盘
当我们的文件上传到手机内部空间后，我们可以使用 dd 来读取手机内部的文件，并写入上文中创建好的分区中，先来恢复 ubuntu 系统分区：
# dd if=/data/root.img of=/dev/block/by-name/ubuntu-os bs=4096
2097152+0 records in
2097152+0 records out
8589934592 bytes transferred in 60.627 secs (141684968 bytes/sec)
接着，我们来恢复 boot 分区：
# dd if=/data/boot.img of=/dev/block/by-name/ubuntu-boot bs=4096
524288+0 records in
524288+0 records out
2147483648 bytes transferred in 13.729 secs (156419524 bytes/sec)
恢复 ESP 分区
想要初始化 EFI 所在的 esp 分区，我们还需要一些额外的操作。
先使用 mkfs.fat 对我们创建好的 esp 分区进行格式化：
# mkfs.fat -F32 -s1 /dev/block/by-name/esp
mkfs.fat 3.0.28 (2015-05-16)
接着，创建一个用于挂载 esp 分区的路径，并使用 mount 将分区挂载到系统中：
mkdir -p /mnt/esp
mount /dev/block/by-name/esp /mnt/esp/
现在，我们就能够将我们下载的数据全部都还原到手机里啦。
cp -r /data/EFI/ /mnt/esp/
第一次启动验证（Grub 可以工作）
虽然，我们知道此时此刻，大概率手机是无法正确引导 Ubuntu 的，但是还是可以重启手机，看看我们距离目标还有多远。
我们在手机上看到了熟悉的 Ubuntu Grub 引导界面，说明 GRUB 相关程序可用。
但是，当读条结束，紧随其后的是一行小字报错：
Invalid header detected on UEFI supplied FDT, ignoring
搜索这个报错，在 Kernel.org 的一次提交记录中，找到了这个 EFI 程序报错：
if (fdt_check_header(fdt) != 0) {
- pr_efi_err("Invalid header detected on UEFI supplied FDT, ignoring ...\n");
+ efi_err("Invalid header detected on UEFI supplied FDT, ignoring ...\n");
return NULL;
}
继续搜索这个函数的名称，在另外一个 Linux 相关的网站上，能够看到这个函数的定义：
// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
/*
* libfdt - Flat Device Tree manipulation
* Copyright (C) 2006 David Gibson, IBM Corporation.
*/
...
int fdt_check_header(const void *fdt)
{
size_t hdrsize;
/* The device tree must be at an 8-byte aligned address */
if ((uintptr_t)fdt & 7)
return -FDT_ERR_ALIGNMENT;
if (fdt_magic(fdt) != FDT_MAGIC)
return -FDT_ERR_BADMAGIC;
if (!can_assume(LATEST)) {
if ((fdt_version(fdt) < FDT_FIRST_SUPPORTED_VERSION)
|| (fdt_last_comp_version(fdt) >
FDT_LAST_SUPPORTED_VERSION))
return -FDT_ERR_BADVERSION;
if (fdt_version(fdt) < fdt_last_comp_version(fdt))
return -FDT_ERR_BADVERSION;
}
hdrsize = fdt_header_size(fdt);
if (!can_assume(VALID_DTB)) {
if ((fdt_totalsize(fdt) < hdrsize)
|| (fdt_totalsize(fdt) > INT_MAX))
return -FDT_ERR_TRUNCATED;
/* Bounds check memrsv block */
if (!check_off_(hdrsize, fdt_totalsize(fdt),
fdt_off_mem_rsvmap(fdt)))
return -FDT_ERR_TRUNCATED;
/* Bounds check structure block */
if (!can_assume(LATEST) && fdt_version(fdt) < 17) {
if (!check_off_(hdrsize, fdt_totalsize(fdt),
fdt_off_dt_struct(fdt)))
return -FDT_ERR_TRUNCATED;
} else {
if (!check_block_(hdrsize, fdt_totalsize(fdt),
fdt_off_dt_struct(fdt),
fdt_size_dt_struct(fdt)))
return -FDT_ERR_TRUNCATED;
}
/* Bounds check strings block */
if (!check_block_(hdrsize, fdt_totalsize(fdt),
fdt_off_dt_strings(fdt),
fdt_size_dt_strings(fdt)))
return -FDT_ERR_TRUNCATED;
}
return 0;
}
虽然，我们不熟悉这块代码和程序实现，但是结合注释和返回“非0”（正确）逻辑来看，应该是我们启动设备过程中的“设备树”相关的配置或者程序有问题。将排查目标转向 “设备树” 或许会有突破。
所以，到目前为止，我们知道了这个方案或许可行，GRUB 可以运行，但是设备树的配置存在问题、GRUB 的配置可能也有问题。
什么是设备树（Device Tree）
可能有的同学第一次听到这个名词，因为在本文中非常有用，所以我们简单展开下。（你可以阅读这篇课程“OSD335x Lesson 2: Linux Device Tree”，来了解更多）
Linux 设备树是一种用于描述硬件配置的数据结构，它独立于操作系统的代码之外，能够将硬件的描述与操作系统代码分离，使得内核可以独立，和设备不耦合。
主要的作用和特点有：
- 硬件描述：设备树文件（.dts）使用一种可读的文本格式，描述系统中的硬件组件、它们的属性和连接关系。
- 可移植性：通过使用设备树，Linux 内核可以在不同的硬件平台上运行，而无需为每个平台定制内核代码。
- 动态加载：设备树在系统启动时被加载到内存中，内核可以动态地访问和解析设备树信息。
- 设备驱动程序：设备树信息有助于简化设备驱动程序的编写，驱动程序可以通过设备树获取必要的硬件信息。
- 二进制格式：设备树源文件需要通过编译工具转换为二进制的设备树 Blob（.dtb），以便内核解析。
- 覆盖机制：通过使用设备树覆盖（Device Tree Overlay），可以在运行时动态地修改设备树，而无需重新编译内核。
第五步：分析手机分区数据
为了解决上面的问题，我们首先需要看看恢复的手机分区内容都是什么呢。
还原现场，静态观察
让我们再次重启手机，将处于 TWRP 模式的手机和电脑相连，然后执行 adb shell 进入交互式环境。
为了确保我们排查的文件和上面手机首次运行的一致，这里我们可以再次重复“第四步”中的步骤，来一个“现场恢复”。
然后，依次执行下面的命令，将上文中的几个分区挂载到手机系统中。
mkdir -p /mnt/esp
mkdir -p /mnt/boot
mkdir -p /mnt/ubuntu
mount /dev/block/by-name/ubuntu-boot /mnt/esp/
mount /dev/block/by-name/ubuntu-boot /mnt/boot/
mount /dev/block/by-name/ubuntu-os /mnt/ubuntu/
接着，我们先来简单查看不同分区中的内容：
# ls /mnt/esp/
System.map-6.5.0-1009-apple-arm efi initrd.img initrd.img.old vmlinuz vmlinuz.old
config-6.5.0-1009-apple-arm grub initrd.img-6.5.0-1009-apple-arm lost+found vmlinuz-6.5.0-1009-apple-arm
# ls /mnt/ubuntu/
bin boot dev etc home lib lost+found media mnt opt proc root run sbin snap srv sys tmp usr var
# ls /mnt/boot/
System.map-6.5.0-1009-apple-arm efi initrd.img initrd.img.old vmlinuz vmlinuz.old
config-6.5.0-1009-apple-arm grub initrd.img-6.5.0-1009-apple-arm lost+found vmlinuz-6.5.0-1009-apple-arm
# ls /mnt/esp/
EFI
/mnt/ubuntu 分区的内容看起来比较正常，目前我们不能确认，也还不需要确认内容是否有问题，可以先跳过，稍后再分析。
/mnt/esp 和 /mnt/boot 分区中的内容，都掌管着设备的启动，尤其是 /mnt/boot 中的文件，看起来有 apple-arm 设备绑定关系，或许需要详细排查。
因为 /mnt/boot 中存在比较多的“冗余文件”，通常情况不需要这么多文件，所以我们不妨先看看，是否存在软链的情况：
raphael:/ # ls -al /mnt/boot/
total 59764
drwxr-xr-x 5 root root 4096 2023-11-07 07:52 .
drwxr-xr-x 6 root system 120 2024-05-05 16:54 ..
-rw------- 1 root root 5478721 2023-10-12 01:57 System.map-6.5.0-1009-apple-arm
-rw-r--r-- 1 root root 265861 2023-10-12 01:57 config-6.5.0-1009-apple-arm
drwxr-xr-x 2 root root 4096 2023-11-07 07:50 efi
drwxr-xr-x 5 root root 4096 2023-11-07 07:52 grub
lrwxrwxrwx 1 root root 31 2023-11-05 05:54 initrd.img -> initrd.img-6.5.0-1009-apple-arm
-rw-r--r-- 1 root root 43770460 2023-11-07 07:52 initrd.img-6.5.0-1009-apple-arm
lrwxrwxrwx 1 root root 31 2023-11-05 05:54 initrd.img.old -> initrd.img-6.5.0-1009-apple-arm
drwx------ 2 root root 16384 2023-11-07 07:50 lost+found
lrwxrwxrwx 1 root root 28 2023-11-05 05:54 vmlinuz -> vmlinuz-6.5.0-1009-apple-arm
-rw------- 1 root root 11645650 2023-10-12 01:57 vmlinuz-6.5.0-1009-apple-arm
lrwxrwxrwx 1 root root 28 2023-11-05 05:54 vmlinuz.old -> vmlinuz-6.5.0-1009-apple-arm
通过上面的信息，我们可以得到简化上面的文件关系：
System.map-6.5.0-1009-apple-arm
config-6.5.0-1009-apple-arm
efi
grub
# 都指向 `initrd.img-6.5.0-1009-apple-arm`
initrd.img -> initrd.img-6.5.0-1009-apple-arm
initrd.img.old -> initrd.img-6.5.0-1009-apple-arm
# 都指向 `vmlinuz-6.5.0-1009-apple-arm`
vmlinuz -> vmlinuz-6.5.0-1009-apple-arm
vmlinuz.old -> vmlinuz-6.5.0-1009-apple-arm
如果这时，我们将手机重启，尝试加载操作系统，然后再重复这一步（第五步）的操作，会发现 /mnt/boot 和 /mnt/esp 分区的内容会变成一致的。
所以，或许我们可以少分析一些内容了。
获取运行后的配置状态
经过反复验证，手机会在启动的时候，将 /boot 目录的内容，完整镜像到 /esp 分区。所以，我们可以再多忽略一个分区的内容（/esp 分区），只对 /boot 分区内容进行分析。
依旧是进入 adb shell 交互终端环境，将 /boot 分区挂载到手机系统中：
mkdir -p /mnt/boot
mount /dev/block/by-name/ubuntu-boot /mnt/boot/
然后，可以使用 adb pull 将手机上的分区数据都下载到本地，方便后续的分析：
# adb pull /mnt/boot ./boot
/mnt/boot/: 244 files pulled, 0 skipped. 30.0 MB/s (179651614 bytes in 5.703s)
分析下载至本地引导程序的问题
我们根据上文中的信息，将本地的文件和目录去重，将得到类似下面的目录内容：
# du -hs *
5.2M System.map-6.5.0-1009-apple-arm
260K config-6.5.0-1009-apple-arm
0B efi
7.8M grub
43M initrd.img
11M vmlinuz
如果你曾经经常安装系统，能够一眼认出来，这不就是 **兼容 UEFI 和 BIOS **的 可引导磁盘/光盘 使用的程序嘛。
直接定位 grub/grub.cfg 中的核心内容，定义启动 Ubuntu 的配置部分：
menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-8fbf3439-8cd7-4734-8fb3-88b8def0a291' {
recordfail
load_video
gfxmode $linux_gfx_mode
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod ext2
search --no-floppy --fs-uuid --set=root b24cb109-0c66-4ea5-bdf3-caf947ed0390
linux /vmlinuz-6.5.0-1009-apple-arm root=UUID=8fbf3439-8cd7-4734-8fb3-88b8def0a291 ro quiet splash $vt_handoff
initrd /initrd.img-6.5.0-1009-apple-arm
}
排除掉各种常规设置配置外，下面这两条指令最可能是不能正常运行的 “罪魁祸首”（关于 GRUB 的资料，感兴趣可以阅读 ArchLinux WIKI 的相关文档或者 GNU 的 GRUB 文档）：
linux /vmlinuz-6.5.0-1009-apple-arm
initrd /initrd.img-6.5.0-1009-apple-arm
在根目录中的 config-6.5.0-1009-apple-arm 配置文件中，我们能够看到生成 vmlinuz 和 initrd.img 使用的配置，或许，我们可以试试用符合这台手机的 Linux 内核和设备树文件，来生成符合引导程序使用的内容。
第六步：构建可用的引导内容
说到构建可用的引导内容，Intel 有一个很好的参考资料：“构建 UEFI 引导加载程序”，如果你感兴趣，也可以了解。
我们简化构建引导程序内容，尤其是生成包含生成 vmlinuz 和 initrd.img 产物内容，一般会有以下几个步骤：
- 准备编译环境，以及准备某个指定版本内核的 Linux 源码。
- 定制内核功能，使用
make menuconfig生成我们需要的构建配置。 - 编译内核源码，得到
bzImage，即：vmlinuz。（参考：为什么 vmlinuz 和 bzImage 是相同的） - 制作
initrd.img携带初始化启动脚本的微型根文件系统。 - 打包文件，更新
grub配置。
虽然上面的制作引导系统的基本流程看起来非常简单，但是实际操作中还是有一些细节需要注意：
- 内核配置项极多；
initrd中要包含必要的设备驱动和工具，需要寻找补全，并需要控制initrd产物的尺寸不要过大（加载不起来）；- 胆大信息，反复调试。
至于编译需要的算力，在 soulteary/Home-Network-Note 项目中，列举了我目前的设备状况，即使前几篇文章中提到的能够当高性能 CI/CD 的 ARM Ubuntu 的设备不能完成构建，也有一些其他的可选项（x86），问题不大。
最后
五一假期最后一天，突然想到了这个方法，至于能否复活这个特别的 “Ubuntu Phone”，让它丝滑的运行 Ubuntu 24.04 和 Docker 程序，接下来相关的文章里，我们来一起试试看吧。
–EOF
我们有一个小小的折腾群，里面聚集了一些喜欢折腾、彼此坦诚相待的小伙伴。
我们在里面会一起聊聊软硬件、HomeLab、编程上、生活里以及职场中的一些问题，偶尔也在群里不定期的分享一些技术资料。
关于交友的标准，请参考下面的文章：
苏洋：致新朋友：为生活投票，不断寻找更好的朋友
当然，通过下面这篇文章添加好友时，请备注实名和公司或学校、注明来源和目的，珍惜彼此的时间 😄
苏洋：关于折腾群入群的那些事
本文使用「署名 4.0 国际 (CC BY 4.0)」许可协议，欢迎转载、或重新修改使用，但需要注明来源。 署名 4.0 国际 (CC BY 4.0)
本文作者: 苏洋
创建时间: 2024年05月06日
统计字数: 18548字
阅读时间: 38分钟阅读
本文链接: https://soulteary.com/2024/05/06/android-natively-run-arm-ubuntu-24-04-desktop-1.html
![Milvus向量数据库（一）Milvus存储byte[]类型源向量数据](https://img-blog.csdnimg.cn/direct/d29a2ae1ca3949f8922855ff24a88938.png)
