做三轨网站犯法吗,做网站需要办什么证件,店铺域名是什么意思,通过法人姓名查企业本篇文章#xff0c;聊一聊尝试让安卓手机原生运行 Ubuntu#xff0c;尤其是运行官方未发布过的 ARM 架构的 Ubuntu 24.04 桌面版本。
写在前面
最近的几篇文章#xff0c;都包含了比较多的实操内容、需要反复的复现验证#xff0c;以及大量的调试过程#xff0c;为了不…本篇文章聊一聊尝试让安卓手机原生运行 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; thenset -eexport LC_ALLen_US.UTF-8export LANGen_US.UTF-8export PATH/usr/bin:/bin:/usr/sbin:/sbin:$PATHexport VERSION_FLAGhttps://cdn.asahilinux.org/installer/latestexport INSTALLER_BASEhttps://cdn.asahilinux.org/installerexport INSTALLER_DATAhttps://ubuntuasahi.org/installer_data.jsonexport REPO_BASEhttps://files.tobhe.de/ubuntu#TMP$(mktemp -d)TMP/tmp/asahi-installecho Bootstrapping installer:if [ -e $TMP ]; thenmv $TMP $TMP-$(date %Y%m%d-%H%M%S)fimkdir -p $TMPcd $TMPecho Checking version...PKG_VER$(curl --no-progress-meter -L $VERSION_FLAG)echo Version: $PKG_VERPKGinstaller-$PKG_VER.tar.gzecho Downloading...curl --no-progress-meter -L -o $PKG $INSTALLER_BASE/$PKGif ! curl --no-progress-meter -L -O $INSTALLER_DATA; thenecho 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_ALTfiecho Extracting...tar xf $PKGecho Initializing...echoif [ $USER ! root ]; thenecho The installer needs to run as root.echo Please enter your sudo password if prompted.exec caffeinate -dis sudo -E ./install.sh $elseexec 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:returnif not package.startswith(http):package os.environ.get(REPO_BASE, .) /os/ packagelogging.info(fOS 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(fOS package opened)原来在下载镜像的时候程序会额外地做一个拼合动作在地址中加一个 /os/ 目录。依样画葫芦拼合上面得到的信息得到能够下载的资源地址
https://files.tobhe.de/ubuntu/os/ubuntu-desktop-23.10-20231107.zip第二步分析 ARM 架构镜像中的“素材”
使用 curl 或者下载工具完成预构建镜像的下载后我们使用 unzip 对其解压缩来看看里面有哪些东西
# unzip ubuntu-desktop-23.10-20231107.zipArchive: ubuntu-desktop-23.10-20231107.zipinflating: 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 的缩写就是 esproot.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) printprintModel: 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 Flags1 24.6kB 32.8kB 8192B switch2 32.8kB 65.5kB 32.8kB ssd3 65.5kB 98.3kB 32.8kB dbg4 98.3kB 131kB 32.8kB bk015 131kB 262kB 131kB bk026 262kB 524kB 262kB bk037 524kB 1049kB 524kB bk048 1049kB 1573kB 524kB keystore9 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 userdata32.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 userdata32.0GB 32.0GB 438kB Free Space
32 32.0GB 32.5GB 499MB fat32 esp boot, esp32.5GB 505GB 473GB Free Space接下来我们分别创建用于存放上文中我们得到的 boot.img 分区镜像和 root.img 分区镜像的分区
mkpart ubuntu-boot fat32 32.5GB 42.5GBmkpart 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 userdata32.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-os505GB 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 -hFilesystem 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 bs409620971520 records in
20971520 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 bs40965242880 records in
5242880 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/espmkfs.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/ubuntumount /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 lostfound vmlinuz-6.5.0-1009-apple-arm# ls /mnt/ubuntu/
bin boot dev etc home lib lostfound 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 lostfound 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 lostfound
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/bootmount /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-arm0B efi
7.8M grub43M initrd.img11M 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 {recordfailload_videogfxmode $linux_gfx_modeinsmod gzioif [ x$grub_platform xxen ]; then insmod xzio; insmod lzopio; fiinsmod ext2search --no-floppy --fs-uuid --setroot b24cb109-0c66-4ea5-bdf3-caf947ed0390linux /vmlinuz-6.5.0-1009-apple-arm rootUUID8fbf3439-8cd7-4734-8fb3-88b8def0a291 ro quiet splash $vt_handoffinitrd /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
